[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219 Stefan Hoffmeister changed: What|Removed |Added CC||stefan.hoffmeister@econos.d ||e --- Comment #4 from Stefan Hoffmeister --- KWIN_DRM_USE_MODIFIERS gates the use of those modifiers, but does not seem to fix the problem. I am on tag v5.25.5 (via Fedora 36) and looking at https://invent.kde.org/plasma/kwin/-/blob/v5.24.5/src/backends/drm/egl_gbm_backend.cpp#L164 suggests that `export KWIN_DRM_USE_MODIFIERS=1` would force-enable use of modifiers, even in the presence of an Nvidia GPU. I have set KWIN_DRM_USE_MODIFIERS=1 (in an .../env startup script) and do not see any change in behaviour in my scenario. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219 --- Comment #5 from Stefan Hoffmeister --- To clarify - I am trying to say that KWIN_DRM_USE_MODIFIERS (on 5.24.5) would have the same effect as the commit. Because KWIN_DRM_USE_MODIFIERS has no effect, I am concerned that the commit might not fix the real problem. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219 --- Comment #6 from Stefan Hoffmeister --- Created attachment 149489 --> https://bugs.kde.org/attachment.cgi?id=149489&action=edit Screenshot of massive CPU load -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219
--- Comment #7 from Stefan Hoffmeister ---
Let me provide some details, observations, and confirmations which may be
helpful (based on v5.24.5 / Fedora 36):
* Wayland
* Notebook with Optimus setup - Intel iGPU + Nvidia dGPU
* Intel GPU has (exclusive) control over the internal display and the HDMI port
("connector")
* Nvidia GPU has (exclusive) control over the USB-C output path (i.e.
DisplayPort Alternate Mode, Thunderbolt Alternative Mode) ("connector")
* Intel is the default (boot) GPU (and cannot be changed)
Log into an empty desktop and attach a 4K external screen to USB-C (which ends
up in a DisplayPort bitstream). The Nvidia GPU remains in "PRIME offload" mode,
but obviously needs the data for presenting.
Any rendering of data strictly towards the Intel-controlled connector remains
smooth. Any rendering towards the Nvidia-controlled connector results in
* an extremely jerky mouse cursor, everything is laggy
* massive CPU load from the kwin_wayland process in response to anything that
requires drawing, even just moving the mouse cursor around
It *feels* almost as if the complete content associated with the 4K screen at
large is transferred even, just for moving the mouse cursor.
Running 'perf trace' suggests that an enormous amount of time is spent on
memmove / memcpy (via glibc optimized functions); the attached screenshot shows
that (and right now I do not know how to produce better diagnostic data)
I tried installing debug symbols via the Fedora service; this got lines
resolved in glibc (the memcpy), but nothing for the KDE process (qt_metacast
smells like dynamic dispatch, so I am not all that surprised).
I turned on DRM logs
(https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues); there was
surprisingly few data, but not being familiar with the domain, I do not know
what to look for in those logs.
I can also confirm the observation that staying on the Intel GPU creates a
smooth experience: Disconnect the external screen from DisplayPort, attach it
to HDMI (Intel connector) - everything is smooth.
In closing, this is the Nvidia 510 driver, the most current driver available
for Fedora 36 from rpmfusion at the time of this writing.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 450110] [nvidia] Poor performances on second monitor with on-demand prime profile
https://bugs.kde.org/show_bug.cgi?id=450110 Stefan Hoffmeister changed: What|Removed |Added CC||stefan.hoffmeister@econos.d ||e --- Comment #1 from Stefan Hoffmeister --- I think it would be very helpful to describe the physical connector setup you are running. Case in point: On X11, I have a setup where * Intel iGPU (only) controls internal display and HDMI * Nvidia dGPU (only) controls the USB-C output path (i.e. DisplayPort Alternate Mode et al) * Nvidia is in PRIME offload mode; Intel is primary Now connect an external 4K screen to the Nvidia output path, i.e. USB-C / DisplayPort. Now the *Xorg* process starts consuming between 25% and 40% of one CPU on an otherwise totally idle system. Remove the 4K screen from the Nvidia output path, attach it to the HDMI port (Intel) Now Xorg is totally fine. Some sleuthing with perf suggests that all that CPU is burnt on getting the current system time (gettimeofday / clock_gettime) via vdso and kernel calls, with this originating from the Nvidia driver (510). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219 --- Comment #8 from Stefan Hoffmeister --- https://bugs.kde.org/show_bug.cgi?id=409040 smells as if it may apply, here, too (and the attached MR https://invent.kde.org/plasma/kwin/-/merge_requests/1861 continues to be open, but a comment there suggests that the Nvidia 515 driver might improve matters?) If timestamps are not accurate, and if kwin then does too much work, then this might end up in consuming by far too much CPU. Someone with domain expertise probably will shoot this down quickly :) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219 --- Comment #9 from Stefan Hoffmeister --- No (observable) change in behaviour for the current Nvidia 515 driver. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 452219] Low fps and high CPU usage on external monitor connected to NVIDIA when default GPU is Intel
https://bugs.kde.org/show_bug.cgi?id=452219 --- Comment #25 from Stefan Hoffmeister --- IIUC, NVIDIA have posted MRs on swaywm and wlroots which touch the rough area of the specific problem reported here: * https://github.com/swaywm/sway/pull/7509 * https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4055 My hardware matches almost exactly what the MR description says: "On most laptops the dGPU does not drive the integrated display, but drives external displays through the HDMI port on the sides/back of the laptop. Plugging in an external display and fullscreening an application on it is what this MR helps." Well, for me it's the USB-C out == Thunderbolt == effectively DisplayPort-alternate where the dGPU lives its life. Perhaps those MR provide some inspiration for kwin. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467771] New: Wayland screen corruption, dual output, dual GPU, different screen resolution
https://bugs.kde.org/show_bug.cgi?id=467771
Bug ID: 467771
Summary: Wayland screen corruption, dual output, dual GPU,
different screen resolution
Classification: Plasma
Product: kwin
Version: 5.27.3
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: wayland-generic
Assignee: kwin-bugs-n...@kde.org
Reporter: stefan.hoffmeis...@econos.de
Target Milestone: ---
Created attachment 157562
--> https://bugs.kde.org/attachment.cgi?id=157562&action=edit
Screen content corruption
KDE / Wayland seems to reliably get confused about which screen is attached to
which output in a multi-GPU setup.
This materializes in bad / wrong / missing invalidation of painting areas,
leaving content garbage in place, and also results in "impossible" state where
Spectacle as a screenshotter claims part of a very much existing screen as
_transparent_.
The attached screenshot shows the broken state; notice
* the red frame I painted in to show the middle screen ("screen #2") in a
triple screen setup
* the bottom-right corner of screen #2, which Spectacle sees as transparent -
but which it is not
* the corruption elsewhere on screen #2
Now particularly note the "clean" area on screen #2 - the dimensions here are
exactly the same as the dimensions of the screen to the left ("screen #3").
AFAICT, this implies that KWin incorrectly uses the dimensions of screen #3 to
compute damage / paint / invalidation areas on screen #2. This then leads to
garbage artefacts on the (larger) screen #2.
Key to reproducing this probably is, unfortunately, a GPU setup where
* iGPU = Intel
* dGPU = Nvidia
and where
* screen #1 == laptop == Intel (right-most screen)
* screen #2 == HDMI port _connected to Intel_
* screen #3 == DisplayPort port _connected to NVIDIA_
and where I used "KWIN_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0" to force the
NVIDIA GPU as the primary GPU (without this forcing, the Intel GPU becomes
primary)
There is no internal mux on the notebook; the outputs are hardwired. In that
setup, the NVIDIA card draws everything, draws natively on screen #3, and
passes data for screen #2 and screen #1 to the Intel GPU for output.
***
For the sake of disclosure, the screenshot comes from a bit of additional
peculiar set of steps - but it highlights much better the exact same effect
seen during "normal operations" with the above setup: The damage / paint area
when drawing on screen #2 is taken from screen #3.
The peculiarity is physically turning off screen #3 (the left-most screen), and
the Thunderbolt docking station apparently keeps some kind of connection alive,
which results in screen #3 still being "seen". But again, I see structurally
the same corruption if I don't do that - it's just so much more evident with
that peculiar step.
I have no idea why I never see corruption on screen #1 or screen #3.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 467771] Wayland screen corruption, dual output, dual GPU, different screen resolution
https://bugs.kde.org/show_bug.cgi?id=467771 --- Comment #1 from Stefan Hoffmeister --- Created attachment 157564 --> https://bugs.kde.org/attachment.cgi?id=157564&action=edit drm_info output of system affected Added drm_info output which might be more effective in communicating the setup than prose. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467771] Wayland screen corruption, dual output, dual GPU, different screen resolution
https://bugs.kde.org/show_bug.cgi?id=467771 --- Comment #2 from Stefan Hoffmeister --- Note: _drawing_ something that is "alive" works just perfectly fine - so putting real content into those affected areas renders just fine. It's, for whatever reason, only whenever content is _not_ painted there that the corruption becomes visible. Leaving, say, a Youtube video playing in the affected areas (i.e. continuous refreshing of that area) results in no corruption. Leaving an empty / idle Kate window in that exact same area will also result in screen corruption over that area, until (in this example) the Kate window gets repainted. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 457130] Bluetooth Remember Previous Status setting works on reboot, but not shutdown
https://bugs.kde.org/show_bug.cgi?id=457130 Stefan Hoffmeister changed: What|Removed |Added CC||stefan.hoffmeister@econos.d ||e --- Comment #4 from Stefan Hoffmeister --- I can confirm the defective behaviour for KDE 5.25.4 (Wayland) on Fedora 36 (up-to-date). I observe the following behaviour: * have KDE desktop running as user "myself", Bluetooth is enabled, Bluetooth mouse, keyboard work * shutdown * cold boot * SDDM comes up - Bluetooth works (mouse and keyboard work) * log into user "myself" * Bluetooth is actively being turned off by KDE * enable Bluetooh Repeat, rinse, lather ... My Bluetooth is built into my notebook, "Bus 003 Device 004: ID 8087:0026 Intel Corp. AX201 Bluetooth", addressed by "BlueZ 5.65" -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 457130] Bluetooth Remember Previous Status setting works on reboot, but not shutdown
https://bugs.kde.org/show_bug.cgi?id=457130 --- Comment #5 from Stefan Hoffmeister --- Elsewhere it was mentioned that Microsoft Windows fast start-up could play a role; this is definintely not the case for me. a) While I do have an installation of Microsoft Windows, my reproducing scenario is strictly the loop "cold boot Fedora 36; clean shutdown from KDE menu" b) Note that SDDM does have working Bluetooth, it's just that KDE turns it off ... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 457130] Bluetooth Remember Previous Status setting works on reboot, but not shutdown
https://bugs.kde.org/show_bug.cgi?id=457130 --- Comment #6 from Stefan Hoffmeister --- Confirmed with KDE 5.25.5 (which just came via Fedora 36 updates). The contents of `~/.config/bluedevilglobalrc ` are ``` [Adapters] xx:xx:xx:xx:xx:xx_powered=false [Devices] connectedDevices= ``` The contents of this file do change if I change the configuration via system settings, e.g. adding: ``` [Global] launchState=enable ``` -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 457130] Bluetooth Remember Previous Status setting works on reboot, but not shutdown
https://bugs.kde.org/show_bug.cgi?id=457130 --- Comment #7 from Stefan Hoffmeister --- >From casual browsing of master of https://invent.kde.org/plasma/bluedevil/-/tree/master/src (i.e. upcoming 5.26) it would seem as if up to https://invent.kde.org/plasma/bluedevil/-/blob/18f444a67f91b0bfeef6ddbbcc9938b2d9c0a971/src/kded/devicemonitor.cpp#L174 all the right things take place (with "bluetoothBlocked", "launchState" not being persisted), which may point towards BluezQt::setBluetoothBlocked doing things it should not be doing? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 457130] Bluetooth Remember Previous Status setting works on reboot, but not shutdown
https://bugs.kde.org/show_bug.cgi?id=457130 --- Comment #9 from Stefan Hoffmeister --- My plan of action is to sprinkle log statements into bluedevil - at least on the restore path -, to add some observability. I am trying to set up a reasonably complete KDE build environment (master) and figure out how to run this (on an isolated account) without putting my system at large at risk. May take a while. Additional data point: Just this night I cold booted into KDE/X11 - and Bluetooth stayed on after logging in from SDDM (i.e. it "remembered"). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 467771] Wayland screen corruption, dual output, dual GPU, different screen resolution
https://bugs.kde.org/show_bug.cgi?id=467771 --- Comment #3 from Stefan Hoffmeister --- https://www.reddit.com/r/Fedora/comments/12j8j1n/have_you_guys_seen_this_screen_glitch_in_kde_what/?utm_source=share&utm_medium=web2x&context=3 looks interesting and possibly related - the symptoms are very similar. Note that the Reddit thread talks about an AMD RX5700 eGPU, attached to a laptop. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 468748] New: Kate on Microsoft Store is out of date
https://bugs.kde.org/show_bug.cgi?id=468748 Bug ID: 468748 Summary: Kate on Microsoft Store is out of date Classification: Applications Product: kate Version: unspecified Platform: Microsoft Windows OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- Kate is generally available on the Microsoft Store, https://apps.microsoft.com/store/detail/kate/9NWMW7BB59HW?hl=en-us&gl=us Alas, the version available _right now_ is "Update Kate to 22.08.1" (which correlates with what is indeed installed) while on https://community.chocolatey.org/packages/kate#versionhistory a newer version has been provisioned for a long time: "Kate 22.12.1 Sunday, January 8, 2023" So, Kate 22.12.1 never made into the Microsoft Store. It would be nice to always and consistently have the most current release version of Kate on the Microsoft Store, to stay up-to-date with Kate. After all the Microsoft Store is the first entry on https://kate-editor.org/get-it/ ;) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477905] New: VMware dynamic guest screen resolution broken (regression on Autofit Guest)
https://bugs.kde.org/show_bug.cgi?id=477905
Bug ID: 477905
Summary: VMware dynamic guest screen resolution broken
(regression on Autofit Guest)
Classification: Plasma
Product: kwin
Version: 5.90.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: stefan.hoffmeis...@econos.de
Target Milestone: ---
When KDE 6.0 Beta 1 runs as a guest inside VMware Workstation 17.5, the desktop
screen resolution no longer adapts dynamically to host window resizing.
This works in KDE 5.27.x in the same virtualization environment, so this has
regressed.
STEPS TO REPRODUCE
1. install VMware Workstation on Fedora Linux 39 (most likely applies to any
host operating system); (trial) download is available from
https://www.vmware.com/products/workstation-pro/workstation-pro-evaluation.html
2. download OpenSUSE Krypton from
http://download.opensuse.org/repositories/KDE:/Medias/images/iso/?P=*Krypton.*.iso
- this is a live image which runs KDE 6 Beta 1 (or later).
3. create a new virtual machine with the OpenSUSE Krypton ISO as a live image
4. boot ISO
// boots fine to a UI
5. resize the VMware Workstation window
OBSERVED RESULT
* screen resolution in KDE 6 remains as-is
EXPECTED RESULT
* screen resolution dynamically adapts to VMware Workstation window size
("Autofit Guest" mode is enabled)
The host does not matter - this occurs on both Fedora Linux 39 and on Windows
11 Professional as a host for VMware Workstation.
I expect that the means of getting a running KDE 6 inside VMware Workstation
does not matter - at this time, using a pre-built fully patched live ISO seems
to be the most reliable way; KDE Neon, Fedora Rawhide + unstable plasma, Fedora
Kinoite + unstable plasma all seem to have various challenges in getting a
fully-configured KDE 6 in place.
The OpenSUSE Krypton live ISO has the open-vm-tools package running; this is
good and required to enable the interaction between the virtual machine host
and the guest operating system (running KDE 6).
The OpenSUSE Krypton live ISO runs X11 by default, but from some trials with
Fedora Rawhide I believe that the same problem exists under Wayland, too
(Fedora Rawhide so far has work-in-progress KDE 6 and issues, so I am not sure
how well this is packaged)
Note that this feature actually works when, instead of VMware Workstation,
VirtualBox 7.0.12 is used as the virtualization platform (alas, VirtualBox has
rather bad virtualization support for graphics at large, making it reasonably
unusable).
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 477905] VMware dynamic guest screen resolution broken (regression on Autofit Guest)
https://bugs.kde.org/show_bug.cgi?id=477905 --- Comment #1 from Stefan Hoffmeister --- Note that, apparently, VirtualBox and VMware Workstation / Player cannot co-exist on the same Linux installation. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477905] VMware dynamic guest screen resolution broken (regression on Autofit Guest)
https://bugs.kde.org/show_bug.cgi?id=477905 Stefan Hoffmeister changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #2 from Stefan Hoffmeister --- Repro steps were bad; the regression remains, though. Creating a new bug. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] New: Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 Bug ID: 477985 Summary: Regression on VMware setting screen resolution (Wayland) Classification: Plasma Product: kwin Version: git master Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY Setting the screen resolution of a virtualized Fedora Rawhide / Plasma 6.0 dev master via VMware Workstation / Player tooling fails to update the screen resolution of the KDE 6 desktop, on Wayland. This breaks, for instance, "full screen" support in VMware Workstation. This is a regression relative to Fedora Linux 39 with KDE 5.27.x on Wayland. This seems to work fine on X11. STEPS TO REPRODUCE 1. have VMware Workstation or VMware Player running as a virtualization solution 2. install and up-to-date Fedora Rawhide (which includes Plasma 6.0 dev master) as a fresh VM // no additional steps are required to get VMware tools in - Fedora Rawhide does this out of the box // observe that this generally works 3. `sudo vmwgfxctrl --set-topology 1920x1080+0+0` OBSERVED RESULT Nothing happens EXPECTED RESULT Virtual screen gets resized to 1920x1080. This applies to setting any screen resolution; above I am using `vmwgfxctrl` for the sake of simplicity, but the same code path (on the VMware side? Linux kernel side?) is most likely taken by * resizing the host virtualized window with "Autofit Guest" feature enabled * putting the VM into full-screen mode (or back) In all cases, the "virtual" screen resolution never changes. Note that setting the screen resolution from _within_ KDE, via "Display Configuration" works (almost always - have not found a reliable way to repro). The drawback of doing that, though, is that this does not allow enabling the peculiar (good) behaviour of "Full-screen mode" in VMware Workstation, where all input is redirected into the VM. The regression therefore does hurt quite a bit in real use of the KDE desktop environment. I do not see any log output, neither in journalctl nor in dmesg, which seem to apply to this scenario. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985
--- Comment #1 from Stefan Hoffmeister ---
I added
```
export QT_LOGGING_RULES="kwin*=true"
```
and whenever I resize the virtual screen from the host, I get
```
Dec 03 19:50:30 fedora kwin_wayland[7208]: kwin_wayland_drm: Received change
event for monitored drm device "/dev/dri/card0"
Dec 03 19:50:30 fedora kwin_wayland[7208]: kwin_wayland_drm: Could not find
edid for connector DrmConnector(id=38, gpu=KWin::DrmGpu(0x558b1858c490),
name="Virtual-1-unknown", connection="Connected", countMode=25)
Dec 03 19:50:30 fedora systemd[1]: vboxclient.service - VirtualBox guest VMSVGA
resize client was skipped because no trigger condition checks were met.
```
The last log entry I just left in to show that the Oracle VirtualBox resize
client is being skipped (as expected).
`drm_info` has this to say:
```
stefan@fedora:~/.config/plasma-workspace/env$ drm_info
drmModeGetFB2: No such device
drmModeGetFB2: No such device
Node: /dev/dri/card0
├───Driver: vmwgfx (Linux drm driver for VMware graphics devices) version
2.20.0 (20211206)
│ ├───DRM_CLIENT_CAP_STEREO_3D supported
│ ├───DRM_CLIENT_CAP_UNIVERSAL_PLANES supported
│ ├───DRM_CLIENT_CAP_ATOMIC supported
│ ├───DRM_CLIENT_CAP_ASPECT_RATIO supported
│ ├───DRM_CLIENT_CAP_WRITEBACK_CONNECTORS supported
│ ├───DRM_CAP_DUMB_BUFFER = 1
│ ├───DRM_CAP_VBLANK_HIGH_CRTC = 1
│ ├───DRM_CAP_DUMB_PREFERRED_DEPTH = 32
│ ├───DRM_CAP_DUMB_PREFER_SHADOW = 0
│ ├───DRM_CAP_PRIME = 3
│ ├───DRM_CAP_TIMESTAMP_MONOTONIC = 1
│ ├───DRM_CAP_ASYNC_PAGE_FLIP = 0
│ ├───DRM_CAP_CURSOR_WIDTH = 64
│ ├───DRM_CAP_CURSOR_HEIGHT = 64
│ ├───DRM_CAP_ADDFB2_MODIFIERS = 1
│ ├───DRM_CAP_PAGE_FLIP_TARGET = 0
│ ├───DRM_CAP_CRTC_IN_VBLANK_EVENT = 1
│ ├───DRM_CAP_SYNCOBJ = 0
│ └───DRM_CAP_SYNCOBJ_TIMELINE = 0
├───Device: PCI 15ad:0405 VMware SVGA II Adapter
│ └───Available nodes: primary, render
├───Framebuffer size
│ ├───Width: [1, 16384]
│ └───Height: [1, 16384]
├───Connectors
│ ├───Connector 0
│ │ ├───Object ID: 38
│ │ ├───Type: virtual
│ │ ├───Status: connected
│ │ ├───Physical size: 0x0 mm
│ │ ├───Subpixel: unknown
│ │ ├───Encoders: {0}
│ │ ├───Modes
│ │ │ ├───2139x1454@60.00 preferred driver nhsync pvsync
│ │ │ ├───3840x2400@59.97 driver phsync nvsync
│ │ │ ├───3840x2160@59.97 driver phsync nvsync
│ │ │ ├───2880x1800@59.95 driver phsync nvsync
│ │ │ ├───2560x1600@59.99 driver nhsync pvsync
│ │ │ ├───2560x1440@59.95 driver phsync nvsync
│ │ │ ├───1920x1440@60.00 driver nhsync pvsync
│ │ │ ├───1856x1392@59.99 driver nhsync pvsync
│ │ │ ├───1792x1344@60.00 driver nhsync pvsync
│ │ │ ├───1920x1200@59.88 driver nhsync pvsync
│ │ │ ├───1920x1080@59.96 driver nhsync pvsync
│ │ │ ├───1600x1200@60.00 driver phsync pvsync
│ │ │ ├───1680x1050@59.95 driver nhsync pvsync
│ │ │ ├───1400x1050@59.98 driver nhsync pvsync
│ │ │ ├───1280x1024@60.02 driver phsync pvsync
│ │ │ ├───1440x900@59.89 driver nhsync pvsync
│ │ │ ├───1280x960@60.00 driver phsync pvsync
│ │ │ ├───1360x768@60.02 driver phsync pvsync
│ │ │ ├───1280x800@59.81 driver phsync nvsync
│ │ │ ├───1152x864@75.00 driver phsync pvsync
│ │ │ ├───1280x768@59.87 driver nhsync pvsync
│ │ │ ├───1280x720@59.85 driver nhsync pvsync
│ │ │ ├───1024x768@60.00 driver nhsync nvsync
│ │ │ ├───800x600@60.32 driver phsync pvsync
│ │ │ └───640x480@59.94 driver nhsync nvsync
│ │ └───Properties
│ │ ├───"DPMS": enum {On, Standby, Suspend, Off} = On
│ │ ├───"link-status": enum {Good, Bad} = Good
│ │ ├───"non-desktop" (immutable): range [0, 1] = 0
│ │ ├───"TILE" (immutable): blob = 0
│ │ ├───"CRTC_ID" (atomic): object CRTC = 40
│ │ ├───"hotplug_mode_update" (immutable): range [0, 1] = 1
│ │ ├───"suggested X" (immutable): range [0, UINT32_MAX] = 0
│ │ └───"suggested Y" (immutable): range [0, UINT32_MAX] = 0
```
The DRM context for this is
```
stefan@fedora:~/.config/plasma-workspace/env$ cat
/sys/class/drm/card0-Virtual-1/status
connected
stefan@fedora:~/.config/plasma-workspace/env$ cat
/sys/class/drm/card0-Virtual-1/modes
2139x1454
3840x2400
3840x2160
2880x1800
2560x1600
2560x1440
1920x1440
1856x1392
1792x1344
1920x1200
1920x1080
1600x1200
1680x1050
1400x1050
1280x1024
1440x900
1280x960
1360x768
1280x800
1152x864
1280x768
1280x720
1024x768
800x600
640x480
stefan@fedora:~/.config/plasma-workspace/env$ cat
/sys/class/drm/card0-Virtual-1/edid
stefan@fedora:~/.config/plasma-workspace/env$
stefan@fedora:~/.config/plasma-workspace/env$
```
highlighting that there indeed is no EDID data.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #2 from Stefan Hoffmeister --- Looking at the code at https://invent.kde.org/plasma/kwin/-/blob/3cc8e9f13bd011670c3a763bdaf3a508b5270a1d/src/backends/drm/drm_connector.cpp#L267 I am not sure how missing EDID data could result in this functional problem? Resizing seems to leave the number of modes unchanged, but changes the content of the _preferred_ mode, so the modes probably are detected as `!equal`, so the mode list gets updated. I do not see why that new / updated preferred mode (at the same position as before) does not get activated. Is there special casing required for "virtual" connectors? Or is "mode has not changed" detection too aggressive? Unfortunately, there is no additional debug logging in that area. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #3 from Stefan Hoffmeister --- More debug output suggests ``` Dec 03 20:30:30 fedora kwin_wayland[1674]: kwin_xwl: Setting primary KWin::DrmOutput(0x55c476dd1b00, name="Virtual-1", geometry=QRect(0,0 1664x1154), scale=1) 33 ``` But ... it does not. The QRect appears correct (and changes with each resize), but ... nothing happens to the screen resolution itself. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478301] New: Log spam "drmPrimeHandleToFD() failed: No such file or directory" (Wayland, virtualization)
https://bugs.kde.org/show_bug.cgi?id=478301 Bug ID: 478301 Summary: Log spam "drmPrimeHandleToFD() failed: No such file or directory" (Wayland, virtualization) Classification: Plasma Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY On every single change of cursor shape (e.g. caret to pointer), log spam is created when run under Wayland, under virtualized graphics (VMware Workstation): ``` Dec 09 13:21:18 fedora kwin_wayland[1633]: kwin_core: Allocating dumb buffer: fd 19 width 64 height 64 Dec 09 13:21:18 fedora kwin_wayland[1633]: kwin_core: drmPrimeHandleToFD() failed: No such file or directory ( 2 ) 1 Dec 09 13:21:18 fedora kwin_wayland[1633]: kwin_scene_qpainter: Failed to allocate a qpainter swapchain graphics buffer Dec 09 13:21:18 fedora kwin_wayland[1633]: kwin_wayland_drm: EglGbmLayerSurface::importWithCpu: failed to get a target dumb buffer ``` STEPS TO REPRODUCE 1. boot Fedora Rawhide (40) under VMware Workstation, running KDE Plasma 6 (git master) 2. open konsole 3. `journalctl --follow` 4. move mouse cursor around such that the pointer changes - e.g. from text field to task bar OBSERVED RESULT * Cursor shape seems to update just fine * Log spam, see above for log lines (note that the log lines contain local modification) EXPECTED RESULT * No log spam SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Rawhide (40), KDE Plasma 6 from git master (also on beta 1), Wayland ADDITIONAL INFORMATION This is on Linux kernel 6.7.rc4. This kernel does not have the cursor plane / hotspot fixes in - https://lore.kernel.org/lkml/87h6lbcixj@minerva.mail-host-address-is-not-set/ -, I guess all this only comes in mid of January 2024, with kernel Linux 6.8. Because of that, the "do not use atomic mode-setting" workaround is still applied by kwin, so this virtual machine has no atomic mode setting active, IIUC. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] New: VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 Bug ID: 478308 Summary: VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint Classification: Plasma Product: kwin Version: git master Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY Running with `export KWIN_DRM_NO_AMS=0` causes KDE Plasma 6 to trigger kernel oops in VMware graphics `vmw_du_cursor_plane_cleanup_fb` on Wayland. This then results in a desktop that doesn't refresh. I tried `KWIN_DRM_NO_AMS=0` explicitly to force rendering onto the default path (i.e. the "do not work around virtual machine challenges"), as this execution path will become active in January 2024, with kernel 6.8 (see recent commits on kwin) and some additions there. I was expecting offset cursors (as on Plasma 5) as a challenge, but right now KDE oopses indeed the kernel, and the desktop is unusable. STEPS TO REPRODUCE 1. configure Wayland + KWIN_DRM_NO_AMS=0 2. log into desktop 3. to some UI work // ... after a very short while kernel oops This is on Fedora Rawhide (40) with kernel 6.7.rc4, KDE Plasma 6 git master (as of this writing; past beta 1) OBSERVED RESULT ``` Dec 09 16:09:08 fedora kernel: BUG: kernel NULL pointer dereference, address: 0028 Dec 09 16:09:08 fedora kernel: #PF: supervisor read access in kernel mode Dec 09 16:09:08 fedora kernel: #PF: error_code(0x) - not-present page Dec 09 16:09:08 fedora kernel: PGD 0 P4D 0 Dec 09 16:09:08 fedora kernel: Oops: [#1] PREEMPT SMP NOPTI Dec 09 16:09:08 fedora kernel: CPU: 4 PID: 710 Comm: kworker/u256:10 Not tainted 6.7.0-0.rc4.20231206gitbee0e7762ad2.37.fc40.x86_64 #1 Dec 09 16:09:08 fedora kernel: Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 Dec 09 16:09:08 fedora kernel: Workqueue: events_unbound commit_work Dec 09 16:09:08 fedora kernel: RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x14d/0x170 [vmwgfx] Dec 09 16:09:08 fedora kernel: Code: 00 00 00 00 00 00 48 8b 44 24 08 65 48 2b 04 25 28 00 00 00 75 29 48 83 c4 10 5b 5d 41 5c c3 cc cc cc cc 48 8b 86 98 00 00 00 <48> 8b 78 28 e8 0a f1 00 00 c6 83 c0 00 00 00 00 e9 d2 fe ff ff e8 Dec 09 16:09:08 fedora kernel: RSP: 0018:c9857e00 EFLAGS: 00010202 Dec 09 16:09:08 fedora kernel: RAX: RBX: 888105edac00 RCX:
[plasmashell] [Bug 478309] New: Content preview windows empty (Wayland, VMware)
https://bugs.kde.org/show_bug.cgi?id=478309 Bug ID: 478309 Summary: Content preview windows empty (Wayland, VMware) Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: stefan.hoffmeis...@econos.de CC: qydwhotm...@gmail.com Target Milestone: 1.0 SUMMARY Running Fedora Rawhide (40) and KDE Plasma 6 (git master, past beta 1) on Wayland, the content preview windows are empty. STEPS TO REPRODUCE 1. log into desktop 2. start some application (Firefox, konsole) 3. hover mouse cursor over task manager entry in bottom panel over running application OBSERVED RESULT Preview window comes up without content. EXPECTED RESULT Preview window comes up with content. Note that this is inside a guest on a VMware Workstation host, i.e. the rendering is going through the kernel's vmwgfx driver; everything on Fedora Rwahide is on the bleeding edge. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478309] Content preview windows empty (Wayland, VMware)
https://bugs.kde.org/show_bug.cgi?id=478309 --- Comment #1 from Stefan Hoffmeister --- At the same time that "no content" pops up up, journalctl shows pipewire errors. I suspect that this unrelated, as pipewire is (largely) about audio, but I am pasting this still: ``` Dec 09 16:36:36 fedora pipewire[1654]: pw.context: params Spa:Enum:ParamId:EnumFormat: 0:0 Invalid argument (input format (no more input formats)) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Object: size 160, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 2 (Spa:Enum:MediaType:video) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 1 (Spa:Enum:MediaSubtype:raw) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 7 (Spa:Enum:VideoFormat:RGBx) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 40 8 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle 1x1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle 1x1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle -1x-1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:modifier (131074), flags 0008 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Long 72057594037927935 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Object: size 136, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 2 (Spa:Enum:MediaType:video) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 1 (Spa:Enum:MediaSubtype:raw) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 7 (Spa:Enum:VideoFormat:RGBx) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 40 8 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle 1x1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle 1x1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle -1x-1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: params Spa:Enum:ParamId:EnumFormat: 1:0 Invalid argument (output format (no more input formats)) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Object: size 272, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 2 (Spa:Enum:MediaType:video) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Id 1 (Spa:Enum:MediaSubtype:raw) Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Rectangle 1174x638 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:framerate (131076), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Fraction 0/1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:maxFramerate (131077), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 40 8 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Fraction 60/1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Fraction 1/1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Fraction 60/1 Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags Dec 09 16:36:36 fedora pipewire[1654]: pw.context: Choice: type Spa:Enum:Choice:Enum, flags 28 4 Dec 09 16:36
[plasmashell] [Bug 478309] Content preview windows empty (Wayland, VMware)
https://bugs.kde.org/show_bug.cgi?id=478309 --- Comment #2 from Stefan Hoffmeister --- Created attachment 164042 --> https://bugs.kde.org/attachment.cgi?id=164042&action=edit Screenshot showing empty preview Attached screenshot showing the empty preview (and parts of the pipewire challenges in the background) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 478309] Content preview windows empty (Wayland, VMware)
https://bugs.kde.org/show_bug.cgi?id=478309 --- Comment #3 from Stefan Hoffmeister --- Note that Fedora Rawhide 40, as I am writing this, does not have the H.264 codec available (yet), so openh264 is not installed (in case that matters) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #4 from Stefan Hoffmeister --- In a different failure mode, the whole desktop becomes unusable due to kwin getting stuck on ``` Dec 10 13:38:31 fedora kwin_wayland[79391]: kwin_wayland_drm: Page flip failed: No space left on device Dec 10 13:38:31 fedora kwin_wayland[79391]: kwin_wayland_drm: Presentation failed! No space left on device ``` To reproduce, have the virtual machine running in "full screen" mode (at 4k), then issue `sudo vmwgfxctrl --set-topology 1920x1080+0+0` At least that shouldn't hang the desktop. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #5 from Stefan Hoffmeister --- Hunting around on the net found https://bugzilla.redhat.com/show_bug.cgi?id=1986240#c32 where Zack Rusin comments in 2021 ``` The KDE issue is a little different. KDE had (it still might, as I haven't tested the latest kwin code) a bug in the kwin wayland code where it wouldn't correct resize the fb dimensions its rendering to after the resize, i.e. looking at https://www.kernel.org/doc/html/latest/gpu/drm-kms.html the drm_framebuffer objects used by kwin aren't correctly resized (recreated with the new dimensions) after udev sends a change event for the new mode on drm_crtc. So while vmwgfx has set the new mode, the userspace is still rendering into old dimensioned framebuffer. ``` The defective "dynamic resize behaviour" that I am reporting seems to be consistent with such a defect: the abstract screen resolution changes, but the buffer which is being painted does not change (i.e. the whole desktop continues to paint into the previous area). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #6 from Stefan Hoffmeister --- Running `~/kde/build/kwin/bin/kwin_wayland --replace` from a separate session (ssh) recovers fine for the KDE Plasma Desktop world, and brings the complete desktop back with the expected (updated!) screen resolution. Alas (obviously) this takes Firefox and friends as victims. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 --- Comment #3 from Stefan Hoffmeister --- (In reply to Neal Gompa from comment #2) > The issue tracker for Linux Direct Rendering Manager (DRM) is: > https://gitlab.freedesktop.org/drm/misc/-/issues > > Please file an issue there. Reported https://gitlab.freedesktop.org/drm/misc/-/issues/34 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 --- Comment #4 from Stefan Hoffmeister --- (In reply to Stefan Hoffmeister from comment #3) > (In reply to Neal Gompa from comment #2) > > The issue tracker for Linux Direct Rendering Manager (DRM) is: > > https://gitlab.freedesktop.org/drm/misc/-/issues > > > > Please file an issue there. > > Reported https://gitlab.freedesktop.org/drm/misc/-/issues/34 FWIW - in https://gitlab.freedesktop.org/drm/misc/-/issues/33#note_2168879 a maintainer writes: "No one reads this issue tracker." I'll try to fill the proper channel to report this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985
--- Comment #8 from Stefan Hoffmeister ---
The root cause of this seems to be a well-intentioned, but eventually
inapplicable, assertion of configuration change, resulting in faulty
suppression of updating:
The implementation tries hard to _not_ change the mode via `drmModeSetCrtc`.
Alas, in the case of resizing of the window ("connector"? "crtc"?) of the
virtual machine, the _mode_ does not appear to change, but the _resolution_
(width, height) changes.
With at least the following crude hack in place, I get a nicely resizing
desktop under KDE Plasma 6 git master on Wayland:
```
const bool modeHasChanged = true || m_pending.mode != m_next.mode;
const bool crtcHasChanged = m_pending.crtc != m_next.crtc;
if (crtcHasChanged || modeHasChanged) {
Error err = legacyModeset();
if (err != Error::None) {
return err;
}
}
```
I currently have a couple more experiments, hacks and log statements in place,
so I am not sure whether the above alone is sufficient - but it is very much
necessary indeed.
Now, obviously,
```
const bool modeHasChanged = true || m_pending.mode != m_next.mode;
```
is just ... crass.
In a different location, I poked
```
const bool isVirtual = (m_conn->connector_type == DRM_MODE_CONNECTOR_VIRTUAL);
```
which may be slight more viable than a simple `true`.
I'd be thrilled to receive suggestions on how to _correctly_ handle "only the
dimensions have changed, but not the mode" scenarios within KDE - I have been
exposed to the combined source code of the Linux DRM kernel subsystem, libdrm,
kwin, Wayland protocols, and QT for only a handful of hours.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 478301] Log spam "drmPrimeHandleToFD() failed: No such file or directory" (Wayland, virtualization)
https://bugs.kde.org/show_bug.cgi?id=478301 --- Comment #1 from Stefan Hoffmeister --- I believe this significantly correlates with Xwayland running into problems in legacy mode; the logs are full of this, too: ``` Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) glamor0: GL error: GL_OUT_OF_MEMORY in glTexSubImage Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) Backtrace: Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 0: /usr/bin/Xwayland (0x55d5958db000+0x17a432) [0x55d595a55432] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 1: /usr/lib64/dri/vmwgfx_dri.so (0x7f5ab640+0x36e0ef) [0x7f5ab676e0ef] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 2: /usr/lib64/dri/vmwgfx_dri.so (0x7f5ab640+0x1aff13) [0x7f5ab65aff13] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 3: /usr/lib64/dri/vmwgfx_dri.so (0x7f5ab640+0x1c2bf8) [0x7f5ab65c2bf8] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 4: /usr/lib64/dri/vmwgfx_dri.so (0x7f5ab640+0x1953ba) [0x7f5ab65953ba] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 5: /usr/lib64/dri/vmwgfx_dri.so (0x7f5ab640+0x198903) [0x7f5ab6598903] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 6: /usr/lib64/dri/vmwgfx_dri.so (0x7f5ab640+0x19f1b9) [0x7f5ab659f1b9] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 7: /usr/bin/Xwayland (0x55d5958db000+0x729f7) [0x55d59594d9f7] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 8: /usr/bin/Xwayland (0x55d5958db000+0x6117a) [0x55d59593c17a] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 9: /usr/bin/Xwayland (0x55d5958db000+0x61911) [0x55d59593c911] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 10: /usr/bin/Xwayland (0x55d5958db000+0x1b9ff5) [0x55d595a94ff5] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 11: /usr/bin/Xwayland (0x55d5958db000+0x1ba748) [0x55d595a95748] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 12: /usr/bin/Xwayland (0x55d5958db000+0x5cb37) [0x55d595937b37] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 13: /usr/bin/Xwayland (0x55d5958db000+0xff76b) [0x55d5959da76b] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 14: /usr/bin/Xwayland (0x55d5958db000+0x11b17a) [0x55d5959f617a] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 15: /usr/bin/Xwayland (0x55d5958db000+0xb5887) [0x55d595990887] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 16: /usr/bin/Xwayland (0x55d5958db000+0x3b840) [0x55d595916840] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 17: /lib64/libc.so.6 (0x7f5ac341d000+0x2814a) [0x7f5ac344514a] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 18: /lib64/libc.so.6 (__libc_start_main+0x8b) [0x7f5ac344520b] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) 19: /usr/bin/Xwayland (0x55d5958db000+0x3d255) [0x55d595918255] Dec 13 08:38:30 fedora kwin_wayland_wrapper[6521]: (EE) ``` Note that in atomic mode-setting mode, the VMware graphics kernel driver seems to crash on a NULL pointer access, also correlated with the above. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] New: Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476
Bug ID: 478476
Summary: Output removal ("remove screen") does not work
(Wayland, Plasma 6)
Classification: Plasma
Product: kwin
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-drm
Assignee: kwin-bugs-n...@kde.org
Reporter: stefan.hoffmeis...@econos.de
Target Milestone: ---
SUMMARY
When removing a previously added (virtual) screen from the system, the udev
change event is received, but is not processed correctly. The result is that
kwin retains the removed output, operates on it, which causes all sorts of (not
very) funny behaviour.
I cannot tell whether this is specific to VMware Workstation in legacy mode
(i.e. not atomic mode-setting); right now, and from the code, it seems as if
this may be generally applicable. I do not have a setup which allows me to
conveniently test that, though.
STEPS TO REPRODUCE
0. have hardware with at least two physical screens attached
1. install Fedora Rawhide (40) + KDE Plasma 6 git master into VMware
Workstation
2. switch VMware Workstation into fullscreen mode (that will _later_ allow
adding additional screens)
3. boot
4. log into (fullscreen) Plasma 6 Wayland session
// cool
5. in VMware Workstation "Cycle multiple monitors" - this adds a new virtual
monitor, new output, new window on host
// cool - this works fine
6. in VMware Workstation "Cycle multiple monitors" - this _removes_ the
previously added virtual monitor/output
OBSERVED RESULT
* kscreen-doctor and vmwgfx agree that only one monitor/output remains
connected
* host window for _second_ monitor/output remains on host screen
* journalctl shows logs with errors (note that this is from a local build with
richer logging)
```
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Received udev
event
KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?|QSocketNotifier::activated|QSocketNotifier::event|QApplicationPrivate::notify_helper
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: udev event:
"change" "/dev/dri/card0"
KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?|QSocketNotifier::activated|QSocketNotifier::event|QApplicationPrivate::notify_helper
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Received change
event for monitored drm device "/dev/dri/card0"
KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?|QSocketNotifier::activated|QSocketNotifier::event|QApplicationPrivate::notify_helper
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Adding outputs
?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?|QSocketNotifier::activated
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Could not find
edid for connector DrmConnector(id=38, gpu=KWin::DrmGpu(0x6fd1a0),
name="Virtual-1-unknown", connection="Connected", countMode=25)
?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Connection on
"Virtual-1-unknown" is in state 1
?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: updateProperties:
modes equal is true
?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Connection on
"Virtual-2-unknown" is in state 2
?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: updateProperties:
mode change detected on "Virtual-2-unknown" for mode index 0 towards 1280 800
?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: updateProperties:
modes equal is false
?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm:
DrmPipeline::legacyModeset
?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm:
DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-1" connected true
?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm: Setting legacy
dpms failed! Invalid argument
?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?
Dec 13 15:12:30 fedora kwin_wayland[8451]: kwin_wayland_drm:
DrmPipeline::legacyModeset
?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #2 from Stefan Hoffmeister --- Created attachment 164144 --> https://bugs.kde.org/attachment.cgi?id=164144&action=edit Immediately after login (before adding screen) ... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #3 from Stefan Hoffmeister --- Created attachment 164145 --> https://bugs.kde.org/attachment.cgi?id=164145&action=edit After adding screen -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #4 from Stefan Hoffmeister --- Created attachment 164146 --> https://bugs.kde.org/attachment.cgi?id=164146&action=edit After removing screen -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 Stefan Hoffmeister changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from Stefan Hoffmeister --- drm_info output attached as requested; running system was Fedora Rawhide (40), fresh up-to-date + COPR KDE Plasma 6 beta 1. I also have a local build environment (with some fixes) where I can see the same behaviour from logs. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #6 from Stefan Hoffmeister --- >From the implementation, I cannot tell how the framebuffer(?) backing the ouput(?) ever gets removed. Basically, as part of the change sequence, the second screen goes into !isConnected with resolution 1280x800, and the current implementation still tries to talk to "it" (connector/output). This fails on various DRM calls: ``` Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: Connection on "Virtual-2-unknown" is in state 2 ?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: updateProperties: mode change detected on "Virtual-2-unknown" for mode index 0 towards 1280 800 ?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: updateProperties: modes equal is false ?libkwin.so.6?|?libkwin.so.6?|KWin::DrmBackend::updateOutputs|KWin::DrmBackend::handleUdevEvent|?libQt6Core.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmPipeline::legacyModeset ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-1" connected true ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: Failed to set legacy property: Invalid argument ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: Setting legacy dpms failed! Invalid argument ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmPipeline::legacyModeset ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-1" connected true ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmPipeline::legacyModeset ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: DrmLegacyCommit::doModeset on "/dev/dri/card0" "Virtual-2" connected false ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? Dec 13 18:24:43 fedora kwin_wayland[3945]: kwin_wayland_drm: drmModeSetCrtc failed: Invalid argument ?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6?|?libkwin.so.6? ``` -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478481] New: DrmPipeline::setCursorLegacy inappropriate invoke of DRM_IOCTL_MODE_CURSOR2
https://bugs.kde.org/show_bug.cgi?id=478481 Bug ID: 478481 Summary: DrmPipeline::setCursorLegacy inappropriate invoke of DRM_IOCTL_MODE_CURSOR2 Classification: Plasma Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY DrmPipeline::setCursorLegacy will only acquire a handle under some conditions, but will use that handle in a call to DRM_IOCTL_MODE_CURSOR2 unconditionally (with a fixed, bad handle value of zero). This is evident from code inspection, but can be diagnosed from logging / error checking once that it is added to the implementation. OBSERVED RESULT With error logging added to the implementation, EINVAL. EXPECTED RESULT No logging. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478481] DrmPipeline::setCursorLegacy inappropriate invoke of DRM_IOCTL_MODE_CURSOR2
https://bugs.kde.org/show_bug.cgi?id=478481 --- Comment #1 from Stefan Hoffmeister --- I have an obvious fix locally, will submit MR. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478481] DrmPipeline::setCursorLegacy inappropriate invoke of DRM_IOCTL_MODE_CURSOR2
https://bugs.kde.org/show_bug.cgi?id=478481 Stefan Hoffmeister changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |INTENTIONAL --- Comment #3 from Stefan Hoffmeister --- Ah, I had missed that magic in the direct use of the ioctl. I had noticed the moral equivalent in the use of drmModeSetCursor in applyPendingChangesLegacy. (The log output, BTW, is real - that's triggered by the kernel vmwgfx driver lying about a GEM driver and managing PRIME <-> handle through TTM. Which means that any attempt to drmCloseBufferHandle that will fail and clobber errno. And I am unable to see any way around that.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #9 from Stefan Hoffmeister --- And then there are * https://github.com/swaywm/wlroots/issues/2188 * https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2188 referring to https://drmdb.emersion.fr/properties/3233857728/hotplug_mode_update which is all about the "hotplug_mode_update" property. GNOME / Mutter is aware of this, https://gitlab.gnome.org/GNOME/mutter/-/blob/main/NEWS#L3132 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #7 from Stefan Hoffmeister --- There are two ways to get a virtual screen removed a) the way described earlier - basically this retains the configuration of the primary screen b) un-maximizing the whole setup, which cause VMware Workstation to collapse everything into a "simple window", causing the primary screen to also resize In the case of a), the second virtual screen does not disappear (as described below). In the case of b), the second virtual screen _does_ in fact disappear. That's a bit of an odd situation, to be honest. I suspect that to have b) working my hack from https://bugs.kde.org/show_bug.cgi?id=477985 needs to be in place, otherwise the resize on the primary screen will not end up well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478487] New: VMware Workstation + atomic mode-settings needs KWIN_FORCE_SW_CURSOR=1
https://bugs.kde.org/show_bug.cgi?id=478487 Bug ID: 478487 Summary: VMware Workstation + atomic mode-settings needs KWIN_FORCE_SW_CURSOR=1 Classification: Plasma Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY When run on VMware Workstation, in Wayland, and with atomic mode-setting force-enabled through export KWIN_DRM_NO_AMS=0 no cursor will be shown. STEPS TO REPRODUCE 0. VMware Workstation 17.5 1. Fedora Rawide (40) + KDE Plasma 6 beta 1 2. have KWIN_DRM_NO_AMS=0 in the environment 3. boot / login OBSERVED RESULT No cursor rendered; cursor is alive and effective though (hover / click etc). EXPECTED RESULT Rendering of cursor. Workaround: export KWIN_FORCE_SW_CURSOR=1 This is on kernel 6.7.0-rc5. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478487] VMware Workstation + atomic mode-settings needs KWIN_FORCE_SW_CURSOR=1
https://bugs.kde.org/show_bug.cgi?id=478487 --- Comment #1 from Stefan Hoffmeister --- With the environment set as above, this seems to work quite well. I used Firefox to render two Youtube videos * one on 4K fullscreen resolution at FullHD * one on 3.5K fullscreen resolution at FullHD plus some more wiggling and rendering experiments and everything looked ok (on an Intel 11800H integrated GPU, which is very much not high performance). I do not know how else to stress atomic mode-setting. Cursor hotspots were perfect, in konsole, in Visual Studio Code, and in Firefox (those tended to cause problem under KDE 5.27 Wayland) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478421] The panel disappeared after entering full screen mode in GNOME Boxes VMs
https://bugs.kde.org/show_bug.cgi?id=478421 Stefan Hoffmeister changed: What|Removed |Added CC||stefan.hoffmeister@econos.d ||e --- Comment #5 from Stefan Hoffmeister --- The video shows what I have reported in words in https://bugs.kde.org/show_bug.cgi?id=477985, and where progress is being made in getting it addressed. The only difference is that the underlying kernel graphics driver here (most likely) is qxl, while for me it is vmwgfx. Both set the hotplug_mode_update DRM property. IMHO, this issue here can be resolved as a duplicate of https://bugs.kde.org/show_bug.cgi?id=477985 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 --- Comment #5 from Stefan Hoffmeister --- As the drm project does not read the issue tracker that they have open for use, I have sent email to the mailing list, see https://lore.kernel.org/all/20231214122709.horde.5iibixwybtitseoti0k2...@webmail.your-server.de/ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478487] VMware Workstation + atomic mode-settings needs KWIN_FORCE_SW_CURSOR=1
https://bugs.kde.org/show_bug.cgi?id=478487 --- Comment #2 from Stefan Hoffmeister --- Digging through the net finds https://github.com/swaywm/sway/issues/5834 and https://github.com/swaywm/sway/issues/3814 - also no way to get hardware cursors to work on the vmwgfx driver, with the workaround also being: force software cursors. There is one report of Weston being able to successfully use hardware cursors on vmwgfx, see https://github.com/swaywm/sway/issues/5834#issuecomment-1234948941 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 --- Comment #6 from Stefan Hoffmeister --- A really good way to make this problem appear is * have KDE Plasma run with atomic mode-setting on, no software cursors * switch to a TTY --> immediate hang of system (in virtual machine) So KDE Plasma + hardware cursor + atomic mode-setting on vmwgfx / VMware Workstation == really, really serious trouble. systemd-logind in this case seems to DRM_IOCTL_DROP_MASTER and there are many more interesting things (for upstream) to look at in kernel logs from the DRM subsystem. The backtrace below is just so much longer (and possibly more meaningful) than what I had before. I'll try to communicate this on the dri-devel mailing list, too. ``` Dec 14 19:06:01 fedora kernel: BUG: kernel NULL pointer dereference, address: 0028 Dec 14 19:06:01 fedora kernel: #PF: supervisor read access in kernel mode Dec 14 19:06:01 fedora kernel: #PF: error_code(0x) - not-present page Dec 14 19:06:01 fedora kernel: PGD 0 P4D 0 Dec 14 19:06:01 fedora kernel: Oops: [#1] PREEMPT SMP NOPTI Dec 14 19:06:01 fedora kernel: CPU: 6 PID: 899 Comm: systemd-logind Not tainted 6.7.0-0.rc5.20231212git26aff849438c.42.fc40.x86_64 #1 Dec 14 19:06:01 fedora kernel: Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 Dec 14 19:06:01 fedora kernel: RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x14d/0x170 [vmwgfx] Dec 14 19:06:01 fedora kernel: Code: 00 00 00 00 00 00 48 8b 44 24 08 65 48 2b 04 25 28 00 00 00 75 29 48 83 c4 10 5b 5d 41 5c c3 cc cc cc cc 48 8b 86 98 00 00 00 <48> 8b 78 28 e8 0a f1 00 00 c6 83 c0 00 00 00 00 e9 d2 fe ff ff e8 Dec 14 19:06:01 fedora kernel: RSP: 0018:c9f4b8c8 EFLAGS: 00010202 Dec 14 19:06:01 fedora kernel: RAX: RBX: 88836c2ada00 RCX: 88810bad Dec 14 19:06:01 fedora kernel: RDX: c02f9500 RSI: 88836c2ada00 RDI: 888103417c38 Dec 14 19:06:01 fedora kernel: RBP: 888103417c38 R08: R09: Dec 14 19:06:01 fedora kernel: R10: R11: R12: Dec 14 19:06:01 fedora kernel: R13: R14: R15: 88810bad Dec 14 19:06:01 fedora kernel: FS: 7f1cf9ae59c0() GS:88842df8() knlGS: Dec 14 19:06:01 fedora kernel: CS: 0010 DS: ES: CR0: 80050033 Dec 14 19:06:01 fedora kernel: CR2: 0028 CR3: 00010e8fe001 CR4: 00f70ef0 Dec 14 19:06:01 fedora kernel: PKRU: 5554 Dec 14 19:06:01 fedora kernel: Call Trace: Dec 14 19:06:01 fedora kernel: Dec 14 19:06:01 fedora kernel: ? __die+0x23/0x70 Dec 14 19:06:01 fedora kernel: ? page_fault_oops+0x171/0x4e0 Dec 14 19:06:01 fedora kernel: ? exc_page_fault+0x7f/0x180 Dec 14 19:06:01 fedora kernel: ? asm_exc_page_fault+0x26/0x30 Dec 14 19:06:01 fedora kernel: ? __pfx_vmw_du_cursor_plane_cleanup_fb+0x10/0x10 [vmwgfx] Dec 14 19:06:01 fedora kernel: ? vmw_du_cursor_plane_cleanup_fb+0x14d/0x170 [vmwgfx] Dec 14 19:06:01 fedora kernel: drm_atomic_helper_cleanup_planes+0x47/0x70 Dec 14 19:06:01 fedora kernel: commit_tail+0xd1/0x130 Dec 14 19:06:01 fedora kernel: drm_atomic_helper_commit+0x11a/0x140 Dec 14 19:06:01 fedora kernel: drm_atomic_commit+0x97/0xd0 Dec 14 19:06:01 fedora kernel: ? __pfx___drm_printfn_info+0x10/0x10 Dec 14 19:06:01 fedora kernel: drm_client_modeset_commit_atomic+0x203/0x250 Dec 14 19:06:01 fedora kernel: drm_client_modeset_commit_locked+0x5a/0x160 Dec 14 19:06:01 fedora kernel: drm_fb_helper_pan_display+0xc9/0x1f0 Dec 14 19:06:01 fedora kernel: fb_pan_display+0x83/0x140 Dec 14 19:06:01 fedora kernel: fb_set_var+0x21a/0x420 Dec 14 19:06:01 fedora kernel: ? __cond_resched+0x36/0x50 Dec 14 19:06:01 fedora kernel: ? __flush_work.isra.0+0x1aa/0x280 Dec 14 19:06:01 fedora kernel: ? update_load_avg+0x7e/0x7d0 Dec 14 19:06:01 fedora kernel: fbcon_blank+0x213/0x310 Dec 14 19:06:01 fedora kernel: do_unblank_screen+0xa9/0x160 Dec 14 19:06:01 fedora kernel: complete_change_console+0x54/0x120 Dec 14 19:06:01 fedora kernel: vt_ioctl+0xd8b/0x13f0 Dec 14 19:06:01 fedora kernel: tty_ioctl+0x4ea/0x8b0 Dec 14 19:06:01 fedora kernel: __x64_sys_ioctl+0x94/0xd0 Dec 14 19:06:01 fedora kernel: do_syscall_64+0x61/0xe0 Dec 14 19:06:01 fedora kernel: ? do_syscall_64+0x70/0xe0 Dec 14 19:06:01 fedora kernel: ? do_syscall_64+0x70/0xe0 Dec 14 19:06:01 fedora kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76 Dec 14 19:06:01 fedora kernel: RIP: 0033:0x7f1cfa5039ed Dec 14 19:06:01 fedora kernel: Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 Dec 14 19:06:01 fedora kernel: RSP: 002b:7fff61c54b80 EFLAGS: 0246 ORIG_RAX: 0010 Dec 14 19:06:01 fedora kernel: RAX: ffda RBX:
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #11 from Stefan Hoffmeister --- Somehow gitlab did not auto-tag https://invent.kde.org/plasma/kwin/-/merge_requests/4790 ... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478421] The panel disappeared after entering full screen mode in GNOME Boxes VMs
https://bugs.kde.org/show_bug.cgi?id=478421 --- Comment #8 from Stefan Hoffmeister --- I see you raising two points in your bug report: a) "The panel disappeared" inside the VM, i.e. with KDE b) "spice ... trying to connect to mutter by dbus" Point a) seems to be the major point, and, as a similarly affected user of KDE Plasma 6, I can confirm that resizing of a virtual screen will simply do that at the moment to KDE. https://bugs.kde.org/show_bug.cgi?id=477985 tracks that, and there is code (there) which "works for me" and which almost certainly will also work for you - best is for you to try the code and provide feedback :) https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceleration seems to be ... exciting ... Point b) would rather be a spice problem, not a KDE problem, I guess? Would the spice / GNOME Boxes developers be interested in that? I am not familiar with those virtualization components, sorry. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478421] The panel disappeared after entering full screen mode in GNOME Boxes VMs
https://bugs.kde.org/show_bug.cgi?id=478421 --- Comment #11 from Stefan Hoffmeister --- I have installed gnome-boxes on Fedora 39 now, created Rawhide virtual machines for GNOME and KDE. Somehow, my setup does seem to work "nicely" in general (very janky), but I could see by running drm_info that on KDE kwin would never update to the resolution changes. The alternative patch you may have seen on the MR mentioned on https://bugs.kde.org/show_bug.cgi?id=477985 should work for you, as virtio-gpu does not ever set the hotplug_mode_update DRM property. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 478600] New: Error: Cannot assign to non-existent property "accentColor"
https://bugs.kde.org/show_bug.cgi?id=478600 Bug ID: 478600 Summary: Error: Cannot assign to non-existent property "accentColor" Classification: Plasma Product: kscreenlocker Version: git-master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY On KDE Plasma 6 Beta 1 (Fedora Rawhide 40) the system log consistenly has warnings: ``` kscreenlocker_greet[5836]: file:///home/stefan/kde/usr/share/plasma/wallpapers/org.kde.image/contents/ui/ImageStackView.qml:107: Error: Cannot assign to non-existent property "accentColor" ``` STEPS TO REPRODUCE 1. KDE Plasma 6 Beta 1 (Fedora Rawhide 40) 2. log into a Wayland session 3. lock screen 4. unlock screen 5. `journalctl -xe` OBSERVED RESULT ``` kscreenlocker_greet[5836]: file:///home/stefan/kde/usr/share/plasma/wallpapers/org.kde.image/contents/ui/ImageStackView.qml:107: Error: Cannot assign to non-existent property "accentColor" ``` EXPECTED RESULT No log entry. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 478600] Error: Cannot assign to non-existent property "accentColor"
https://bugs.kde.org/show_bug.cgi?id=478600 --- Comment #1 from Stefan Hoffmeister --- Note that this actually may be running KDE Plasma 6 git master (self-built); if so, I am able to rebuild plasma-desktop and test fixes. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 478601] New: Each unlock "qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000)"
https://bugs.kde.org/show_bug.cgi?id=478601 Bug ID: 478601 Summary: Each unlock "qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000)" Classification: Plasma Product: kscreenlocker Version: git-master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY On KDE Plasma 6 Beta 1 (Fedora Rawhide 40) every screen unlock yields log entries ``` Dec 16 11:33:12 fedora kscreenlocker_greet[13371]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) Dec 16 11:33:12 fedora kscreenlocker_greet[13371]: Failed to write to the pipe: Bad file descriptor. ``` STEPS TO REPRODUCE 1. KDE Plasma 6 Beta 1 (Fedora Rawhide 40) 2. log into a Wayland session 3. lock screen 4. unlock screen 5. `journalctl -xe` OBSERVED RESULT Log entries ``` Dec 16 11:33:12 fedora kscreenlocker_greet[13371]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) Dec 16 11:33:12 fedora kscreenlocker_greet[13371]: Failed to write to the pipe: Bad file descriptor. ``` EXPECTED RESULT No log entries (which is not to mean that the log entries get a lower log level, but that any presumed root cause be removed) ADDITIONAL INFORMATION FWIW, 0x3000 == EGL_SUCCESS, so I am a bit surprised about the log message? Note that this is running inside a virtual machine, on the vmwgfx Linux kernel drm driver, with atomic mode-setting explicitly enabled, and with software cursors forced on. I would speculate that this is not relevant to the issue. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 477985] Regression on VMware setting screen resolution (Wayland)
https://bugs.kde.org/show_bug.cgi?id=477985 --- Comment #12 from Stefan Hoffmeister --- Another MR with a different change detection strategy: https://invent.kde.org/plasma/kwin/-/merge_requests/4799 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 478090] [NVIDIA] locking 2nd time in a Wayland session results in black screen with cursor
https://bugs.kde.org/show_bug.cgi?id=478090 Stefan Hoffmeister changed: What|Removed |Added CC||stefan.hoffmeister@econos.d ||e --- Comment #4 from Stefan Hoffmeister --- I see the same behaviour on vmwgfx - i.e. a virtual machine running on top of VMware Workstation. The only way I have found to recover from this is to resize the virtual machine's window. This works well for a virtual machine, but still is annoying. FWIW, I am not sure about the "second time" - it's hit and miss for me, much more often hit the problem than missing it. This is on Fedora Rawhide 40 with (I suspect) my self-built plasma-desktop in place from git master. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 478090] [NVIDIA] locking 2nd time in a Wayland session results in black screen with cursor
https://bugs.kde.org/show_bug.cgi?id=478090 --- Comment #5 from Stefan Hoffmeister --- I just had this happen again. It may correlate with timeouts, where "something" turns off? My VM is running in the background - KDE will simply (eventually) turn off the virtual screen. Curious: the mouse cursor was a pointing finger, not an arrow. Literally the only way for me to recover was the magic "change screen size in virtual machine" work-around. No amount of clicking, hacking away at the keyboard, sending keystrokes into virtual machine did anything. At the same time, I was enjoying exactly no warnings in the SSH session. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478616] New: System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616 Bug ID: 478616 Summary: System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..." Classification: Plasma Product: kwin Version: 5.27.10 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY On Fedora 39 + KDE Plasma 5.27.10 + Wayland on native notebook hardware including * NVIDIA 3060 RTX mobile GPU * Intel Tiger Lake 11800H iGPU I seem to start getting random system hands on boot to a graphical desktop; the log then contains ``` Dec 15 18:25:24 dell-7610.home sddm-helper-start-wayland[2560]: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)\nkwin_wayland_drm: failed to open drm device at \"/dev/dri/card0\"\n" ``` In such a state, the system simply hangs dead with a blank screen for a handful of seconds (15? 25?). It will then show on screen the notebook vendor's boot logo. And stay there. The logs for this are ``` Dec 16 20:19:03 dell.home sddm-helper-start-wayland[2515]: "No backend specified, automatically choosing drm\n" ... Dec 16 20:19:30 dell.home sddm-helper-start-wayland[2515]: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)\nkwin_wayland_drm: failed to open drm device at \"/dev/dri/card0\"\nkwin_wayland_drm: No suitable DRM devices have been found\n" Dec 16 20:19:30 dell.home sddm-greeter[2518]: Creating a fake screen in order for Qt not to crash Dec 16 20:19:30 dell.home sddm-greeter[2518]: The Wayland connection broke. Did the Wayland compositor die? Dec 16 20:19:30 dell.home sddm-helper-start-wayland[2515]: Stopping... "/usr/bin/sddm-greeter" Dec 16 20:19:30 dell.home sddm-helper[2420]: pam_unix(sddm-greeter:session): session closed for user sddm ``` The "native" GPU sequence (which I cannot change in the BIOS) is, * /dev/dri/card0 == Intel * /dev/dri/card1 == NVIDIA Now, SDDM has peculiar configuration to force on Wayland and to exclude the NVIDIA card in /etc/sddm.conf.d/someconfig.conf ``` [General] DisplayServer=wayland GreeterEnvironment=QT_WAYLAND_SHELL_INTEGRATION=layer-shell,KWIN_DRM_DEVICES=/dev/dri/card0 ``` Physically connected are * the notebooks's internal display and an HDMI screen are alive and alight on Intel GPU (card0) * a 2.5K screen is on Thunderbolt -> DisplayPort on the NVIDIA GPU (card1) STEPS TO REPRODUCE 1. have setup as described above 2. boot OBSERVED RESULT Every once in a while, the system hangs dead with the above symptoms. EXPECTED RESULT Reliable start to SDDM greeter. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478616] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616
--- Comment #1 from Stefan Hoffmeister ---
I am reporting this against kwin because of the implementation in `int
LogindSession::openRestricted(const QString &fileName)` with the origin of the
log entry evidently being
```
const QDBusMessage reply = QDBusConnection::systemBus().call(message);
if (reply.type() == QDBusMessage::ErrorMessage) {
qCWarning(KWIN_CORE, "Failed to open %s device (%s)",
qPrintable(fileName), qPrintable(reply.errorMessage()));
return -1;
}
```
>From context it is clear that the _device_ exists (10 lines earlier, the `stat`
succeeds).
>From a user perspective, it may be beneficial to establish
* a _shorter_ timeout on the dbus call
* a mechanism for exponential back-off retries, capped to, say 30 seconds in
kwin_core, in trying to acquire the device
but I have no idea whether that is feasible at all.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 478616] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616 --- Comment #2 from Stefan Hoffmeister --- Based on comments in https://bbs.archlinux.org/viewtopic.php?id=250684 I looked at there being a chance of racing between drm and systemd-logind (which apparently is responsible for handing out the file handle to card0). In the two blocks below based on `journalctl -b | grep -E '\[drm\]|systemd-login'`, I do not see much of a difference in ordering, and none that would seem to matter (not that I would be competent in assessing that): ``` +++ broken fedora kernel: i915 :00:02.0: [drm] VT-d active for gfx access fedora kernel: i915 :00:02.0: [drm] Using Transparent Hugepages fedora kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12) fedora kernel: i915 :00:02.0: [drm] GT0: GuC firmware i915/tgl_guc_70.1.1.bin version 70.1.1 fedora kernel: i915 :00:02.0: [drm] GT0: HuC firmware i915/tgl_huc_7.9.3.bin version 7.9.3 fedora kernel: i915 :00:02.0: [drm] GT0: HuC: authenticated for all workloads fedora kernel: i915 :00:02.0: [drm] GT0: GUC: submission enabled fedora kernel: i915 :00:02.0: [drm] GT0: GUC: SLPC enabled fedora kernel: i915 :00:02.0: [drm] GT0: GUC: RC enabled fedora kernel: i915 :00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized fedora kernel: [drm] Initialized i915 1.6.0 20201103 for :00:02.0 on minor 0 fedora kernel: i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device fedora kernel: i915 :00:02.0: [drm] Selective fetch area calculation failed in pipe A fedora systemd[1]: Starting systemd-logind.service - User Login Management... fedora systemd-logind[1520]: New seat seat0. fedora systemd-logind[1520]: Watching system buttons on /dev/input/event1 (Power Button) fedora systemd-logind[1520]: Watching system buttons on /dev/input/event0 (Lid Switch) fedora systemd-logind[1520]: Watching system buttons on /dev/input/event2 (Sleep Button) fedora systemd-logind[1520]: Watching system buttons on /dev/input/event15 (Intel HID events) fedora systemd-logind[1520]: Watching system buttons on /dev/input/event16 (Intel HID 5 button array) fedora systemd-logind[1520]: Watching system buttons on /dev/input/event3 (AT Translated Set 2 keyboard) fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' fedora systemd[1]: Started systemd-logind.service - User Login Management. fedora kernel: [drm] [nvidia-drm] [GPU ID 0x0100] Loading driver dell.home systemd-logind[1520]: Watching system buttons on /dev/input/event8 (Cherry GmbH CHERRY Corded Device) dell.home kernel: [drm] Initialized nvidia-drm 0.0.0 20160202 for :01:00.0 on minor 1 dell.home kernel: nvidia :01:00.0: [drm] Cannot find any crtc or sizes dell.home systemd-logind[1520]: Watching system buttons on /dev/input/event10 (Generic USB Audio Consumer Control) dell.home kernel: nvidia :01:00.0: [drm] fb1: nvidia-drmdrmfb frame buffer device dell.home systemd-logind[1520]: New session c1 of user sddm. dell.home systemd-logind[1520]: Session c1 logged out. Waiting for processes to exit. dell.home systemd-logind[1520]: Removed session c1. dell.home systemd-logind[1520]: New session 2 of user stefan. dell.home systemd-logind[1520]: The system will reboot now! dell.home systemd-logind[1520]: System is rebooting. dell.home systemd-logind[1520]: Session 2 logged out. Waiting for processes to exit. dell.home systemd[1]: Stopping systemd-logind.service - User Login Management... dell.home systemd-logind[1520]: Removed session 2. dell.home systemd[1]: systemd-logind.service: Deactivated successfully. dell.home audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-logind comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' dell.home systemd[1]: Stopped systemd-logind.service - User Login Management. ``` ``` +++ working fedora kernel: i915 :00:02.0: [drm] VT-d active for gfx access fedora kernel: i915 :00:02.0: [drm] Using Transparent Hugepages fedora kernel: i915 :00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12) fedora kernel: i915 :00:02.0: [drm] GT0: GuC firmware i915/tgl_guc_70.1.1.bin version 70.1.1 fedora kernel: i915 :00:02.0: [drm] GT0: HuC firmware i915/tgl_huc_7.9.3.bin version 7.9.3 fedora kernel: i915 :00:02.0: [drm] GT0: HuC: authenticated for all workloads fedora kernel: i915 :00:02.0: [drm] GT0: GUC: submission enabled fedora kernel: i915 :00:02.0: [drm] GT0: GUC: SLPC enabled fedora kernel: i915 :00:02.0: [drm] GT0: GUC: RC enabled fedora kernel: i915 :00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized fedora k
[kwin] [Bug 478616] [NVIDIA] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616
--- Comment #3 from Stefan Hoffmeister ---
I got the reject on the Intel card ("/dev/dri/card0") again this morning, on a
modified system configuration. I had tried to mitigate this issue by modifying
the following two configuration parts on my system:
* modified sddm configuration to remove KWIN_DRM_DEVICES (i.e. sddm may now use
primary card0 == Intel and card1 == nvidia) - it is still force-configured to
use Wayland
* added all nvidia modules to `/etc/modules-load.d/nvidia.conf` and rebuilt
initramfs via `dracut --regenerate-all --force` (cf `lsinitrd`)
Additionally, other than before, the NVIDIA GPU did not have any output
connected.
In the logs (excerpt below) this is what I see:
* the session for user sddm comes up fine
* dbus-broker.service seems to have successfully started
* there is SELinux denial for sys_admin on systemd-modules (triggered by AVC
`avc: denied { sys_admin } for pid=1483 comm="nv_queue"`), but that would be
NVIDIA matching the nv_queue kernel thread, if at all (and frankly, I suspect
that this is a defect elsewere, because the whole point of systemd-modules _is_
loading modules as an admin?)
* kwin_wayland terminates with an error while trying to get hold of the Intel
card "/dev/dri/card0"
* sddm? kwin? tries again on the NVIDIA card (`sddm-helper-start-wayland[2526]:
"OpenGL vendor string: NVIDIA Corporation`)
* sddm-greeter does not find a screen (correct, the NVIDIA GPU does not have a
screen attached, and I don't think it would be reasonable for the NVIDIA GPU to
be able to talk to the apparently not-so-happy Intel GPU at this stage)
So, right now I am mostly interested in maximizing relevant log output from
* sddm
* dbus (traffic)
* systemd-logind (accessing /dev/dri/card0)
in the hope to get more context.
FWIW, I recall one more peculiarity on this system: I am forcing the
non-default Intel GPU firmware loading for guc and huc (`options i915
enable_guc=3`), see https://wiki.archlinux.org/title/intel_graphics . Turning
this off for now.
```
Dec 17 08:24:37 dell.home systemd-logind[1684]: New session c1 of user sddm.
Dec 17 08:24:37 dell.home systemd[1]: Started uresourced.service - User
resource assignment daemon.
Dec 17 08:24:37 dell.home audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=uresourced
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
Dec 17 08:24:37 dell.home systemd[1]: Finished user-runtime-dir@988.service -
User Runtime Directory /run/user/988.
Dec 17 08:24:37 dell.home audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=user-runtime-dir@988
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
Dec 17 08:24:37 dell.home systemd[1]: Starting user@988.service - User Manager
for UID 988...
Dec 17 08:24:37 dell.home dbus-broker-launch[1599]: Activation request for
'org.freedesktop.home1' failed: The systemd unit
'dbus-org.freedesktop.home1.service' could not be found.
Dec 17 08:24:37 dell.home audit[2508]: USER_ACCT pid=2508 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:accounting
grantors=pam_unix acct="sddm" exe="/usr/lib/systemd/systemd" hostname=? addr=?
terminal=? res=success'
Dec 17 08:24:37 dell.home audit[2508]: CRED_ACQ pid=2508 uid=0 auid=4294967295
ses=4294967295 subj=system_u:system_r:init_t:s0 msg='op=PAM:setcred grantors=?
acct="sddm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=failed'
Dec 17 08:24:37 dell.home audit[2508]: USER_ROLE_CHANGE pid=2508 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='pam:
default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 17 08:24:37 dell.home (systemd)[2508]: pam_unix(systemd-user:session):
session opened for user sddm(uid=988) by sddm(uid=0)
Dec 17 08:24:37 dell.home audit[2508]: USER_START pid=2508 uid=0 auid=988 ses=1
subj=system_u:system_r:init_t:s0 msg='op=PAM:session_open
grantors=pam_selinux,pam_selinux,pam_loginuid,pam_keyinit,pam_namespace,pam_systemd_home,pam_umask,pam_keyinit,pam_limits,pam_systemd,pam_unix
acct="sddm" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
res=success'
Dec 17 08:24:37 dell.home uresourced[2484]: Setting resources on user.slice
(MemoryMin: 262144000, MemoryLow: 0, CPUWeight: -, IOWeight: -)
Dec 17 08:24:37 dell.home uresourced[2484]: Setting resources on user-988.slice
(MemoryMin: 262144000, MemoryLow: 0, CPUWeight: 500, IOW
[kwin] [Bug 478616] [NVIDIA] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616 --- Comment #4 from Stefan Hoffmeister --- FWIW, I am concerned that this issue here has been sent into the direction of "NVIDIA" - while there certainly is NVIDIA hardware in this system, at least some failures were with KWIN_DRM_DEVICES=/dev/drm/card0 which ties this straight to Intel. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478616] [NVIDIA] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616
--- Comment #5 from Stefan Hoffmeister ---
Right now it is a lottery game whether I get to the sddm prompt, without
""kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. "
Some findings:
* Intel firmware (removing the non-default `guc=3`) does not make a difference
* only with KWIN_DRM_DEVICES=/dev/drm/card0 for sddm do I get the change to
switch to a console (Ctrl+Alt+F4), so this option is back on, as on this
notebook I never want to have the NVIDIA GPU (card1) drive the graphical login
* `reboot` from the console ends up in the graphics stack again, so never
reboots successfully; I have to use ACPI power down (hold power button for 10
seconds) to force shutdown
Just for laughs, I have now set selinux policy from enforcing to permissive
("/etc/selinux/config"). The boot after doing that worked (and I am writing
this from a working session).
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 478616] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616
--- Comment #6 from Stefan Hoffmeister ---
It appears as if - somehow - this is indeed related to the NVIDIA driver "being
around".
With all prior changes reverted and only the following changes on place, I now
again get reliable boots into a KDE Plasma graphical user interface:
* blacklist modules nvidia, nvidia-drm, nvidia-modeset, nvidia-uvm
("/etc/modprobe.d/nvidia-blacklist.conf")
* dracut blacklist the above modules
("/lib/dracut/dracut.conf.d/99-nvidia-dracut.conf")
* set module parameter "options nvidia_drm fbdev=0"
("/etc/modprobe.d/nvidia_drm.conf") - this is somewhat pointless given that the
module is blacklisted, but on my system I will never need an NVIDIA framebuffer
* mask falling back to the nouveau driver ("systemctl mask
nvidia-fallback.service")
The net effect of this is that "lsmod | grep -E '^(nvidia|nouveau)'" will
return only
```
nvidia_uvm 3522560 0
nvidia 62394368 9 nvidia_uvm
```
which _disables_ the complete graphics stack (including NVIDIA Prime with
OpenGL / Vulkan), but which _retains_ the ability run NVIDIA CUDA processing
loads (I cannot explain at this time where nvidia_uvm actually gets loaded).
There also seems to have been some kind of interaction with multiple screens
attached (all of them attached to the Intel GPU, though!) - booting with a
single screen seems to have always worked.
FWIW, I do not have a GNOME installation on this box, so I am unable to tell
whether this would be affected as well; by the look-and-feel of everything, I
would suspect that GNOME would suffer from exactly the same problems.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #8 from Stefan Hoffmeister --- Tested the "cycle multiple monitors" feature of VMware Workstation on Fedora Workstation Rawhide F40 - it works there. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476
--- Comment #9 from Stefan Hoffmeister ---
The root cause of this defect is a design challenge in the atomic commit code.
Whenever an output is changed ("DrmGpu::updateOutputs"), among other things,
the 1:1 matched up internal processing pipeline of kwin gets "managed", too.
The GPU _instance_ retains a list of those pipelines in m_pipelines. When a new
pipeline is added, it is added immediately to m_pipelines. When a pipeline is
removed, it is immediately removed from m_pipelines.
After the GPU instance state for pipelines has been altered, all this gets
tested and ends up in DrmGpu::testPipelines(). This then does
commitPipelines(m_pipelines, DrmPipeline::CommitMode::TestAllowModeset. This
will pass, and all is good - new configuration is accepted.
Alas, what is missing is a successful atomic commit to clean up any _removed_
pipeline(s) all the way into the _kernel_. This has the effect that the _DRM
plane_ that was connected to the removed pipeline still has a framebuffer
object attached to it that is now frozen in time, because nothing ever updates
it. And because there is still that framebuffer object around, the VMware
Workstation host will faithfully show that forever.
This behaviour is best illustrated by adding one single log statement to the
implementation:
```
DrmPipeline::Error DrmPipeline::commitPipelinesAtomic(const QList &pipelines, CommitMode mode, const QList &unusedObjects)
{
+ qCDebug(KWIN_DRM) << "commitPipelinesAtomic is applied to" <<
pipelines.size() << "pipelines";
```
Notice how this will print the number(a) as explained above - numbers that are
not good ;). Also inspect the output of drm_info gathered in attachement "After
removing screen" and notice how plane 2 (which is the removed screen) still has
a non-zero framebuffer buffer ID (FB_ID) value (96)
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 478476] Output removal ("remove screen") does not work (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=478476 --- Comment #10 from Stefan Hoffmeister --- As far as I can see, this defect only hits systems where an output does not _physically_ disappear. Or, in other words, if you plug the cable, well, there is nothing coming down that wire any more, right? So, this will most likely only detrimentally _affect_ systems with non-physical screens which allow multi-screen configurations. Such as (confirmed) VMware Workstation (and most likely all desktop hypervisor products created by VMware, for instance VMware Fusion). Perhaps GNOME Boxes / qemu / kvm (with virtio-gpu)? Perhaps VirtualBox? Perhaps whatever is using the qxl driver? Whatever does virtualization and software abstraction tricks. It will also only _affect_ users of said systems who turn on and _off_ one more screens in addition to the primary screen. So while the defect is universal, after triage, its impact (most likely) is rather limited. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478616] System hangs dead on sddm start: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. ..."
https://bugs.kde.org/show_bug.cgi?id=478616 --- Comment #7 from Stefan Hoffmeister --- This does not seem to be related to NVIDIA. Right now I suspect multi-monitor support on the Intel 11800H iGPU (there is a 4K screen attached to that GPU, but the monitor has been working very fine going through all of the Plymouth "nice animated system boot" graphics fun) Reason: I have now had a cold boot on this notebook (power on after having been turned off for six hours) and got the same problem, again. With more logging enabled, it is now clear that systemd_logind simply does not respond in time: * 09:35:52 - kwin_wayland (apparently) sends the TakeDevice request via dbus * 09:35:52 - systemd_logind acks request [25 secs after request] * 09:36:17 - kwin_wayland gives up waiting, "Failed to open /dev/dri/card0 device"; sddm is toast [34 secs after request] * 09:36:26 - systemd_logind sends response, apparently a success ``` Dec 20 09:35:52 dell.home systemd[2417]: Started dbus-broker.service - D-Bus User Message Bus. Dec 20 09:35:52 dell.home dbus-broker-launch[2448]: Ready Dec 20 09:35:52 dell.home systemd-logind[1531]: Got message type=method_call sender=:1.36 destination=org.freedesktop.login1 path=/org/freedesktop/login1/session/c1 interface=org.freedesktop.login1.Session member=TakeDevice cookie=15 reply_cookie=0 signature=uu error-name=n/a error-message=n/a Dec 20 09:35:54 dell.home kernel: thunderbolt 0-1: new device found, vendor=0x16b device=0x9010 Dec 20 09:35:54 dell.home kernel: thunderbolt 0-1: i-tec TB3CDUALDPDOCKPD Dec 20 09:35:54 dell.home boltd[1725]: [004158c8-bd26-TB3CDUALDPDOCKPD ] parent is f07211eb-5a97... Dec 20 09:35:54 dell.home boltd[1725]: [004158c8-bd26-TB3CDUALDPDOCKPD ] connected: authorized (/sys/devices/pci:00/:00:0d.2/domain0/0-0/0-1) Dec 20 09:35:54 dell.home boltd[1725]: [004158c8-bd26-TB3CDUALDPDOCKPD ] udev: device changed: authorized -> authorized Dec 20 09:36:01 dell.home systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully. Dec 20 09:36:01 dell.home audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Dec 20 09:36:17 dell.home sddm-helper-start-wayland[2433]: "kwin_core: Failed to open /dev/dri/card0 device (Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.)\nkwin_waylan> Dec 20 09:36:17 dell.home sddm-greeter[2444]: Creating a fake screen in order for Qt not to crash Dec 20 09:36:17 dell.home sddm-greeter[2444]: The Wayland connection broke. Did the Wayland compositor die? Dec 20 09:36:17 dell.home sddm-helper-start-wayland[2433]: Stopping... "/usr/bin/sddm-greeter" Dec 20 09:36:17 dell.home sddm-helper[2323]: pam_unix(sddm-greeter:session): session closed for user sddm ... Dec 20 09:36:26 dell.home systemd-logind[1531]: Sent message type=method_return sender=n/a destination=:1.36 path=n/a interface=n/a member=n/a cookie=73 reply_cookie=15 signature=hb error-name=n/a error-message=n/a ``` -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 --- Comment #7 from Stefan Hoffmeister --- VMware have reacted on the dri gitlab issue tracker, ACKed the report, confirmed reproduction on their end, and noted that they now have an internal tracking item for this. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 477238] Display resolution and scaling settings not persistent
https://bugs.kde.org/show_bug.cgi?id=477238 Stefan Hoffmeister changed: What|Removed |Added CC||stefan.hoffmeister@econos.d ||e --- Comment #10 from Stefan Hoffmeister --- Sounds like https://invent.kde.org/plasma/kwin/-/merge_requests/4913 which was only recently merged. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479002] New: Wayland atomic mode-setting cursors not shown on vmwgfx driver
https://bugs.kde.org/show_bug.cgi?id=479002 Bug ID: 479002 Summary: Wayland atomic mode-setting cursors not shown on vmwgfx driver Classification: Plasma Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY When forcing on atomic mode-setting through `export KWIN_DRM_NO_AMS=0` on KDE Plasma 6 git master (beta2+) in a Wayland session, on VMware Workstation (vmwgfx kernel driver), no cursor is shown. Looking at `watch -n 1 "drm_info | grep -E 'Plane|Connector|FB_ID|\"CRTC'"` suggests that the plane is assigned to the right CRTC, that the FB_ID changes. There is no applicable log output at level debug+. STEPS TO REPRODUCE 1. force atomic mode-setting to on via `export KWIN_DRM_NO_AMS=0` 2. make sure that software cursors are _not_ on (i.e. _not_ KWIN_FORCE_SW_CURSOR=1) 3. log into Plasma Wayland session OBSERVED RESULT No cursor visible on screen, but system _acts_ as if there is a cursor present (clicks etc work) EXPECTED RESULT Cursor visible on screen. ADDITIONAL INFORMATION Note that right now forcing on of KWIN_DRM_NO_AMS is required due to the Linux kernel (virtual graphics drivers) lacking some capabilities in version 6.7.0-rc5. With Linux kernel 6.8 these capabilities will be present in the kernel and kwin will automatically enable atomic mode-setting. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478308] VMware kernel oops with KWIN_DRM_NO_AMS=0; desktop does not repaint
https://bugs.kde.org/show_bug.cgi?id=478308 --- Comment #8 from Stefan Hoffmeister --- There is a working patch in https://lore.kernel.org/all/20231225202541.horde.txckv5njboomrzjolmts...@webmail.your-server.de/ which fixes the oops. With that patch in place, it is now possible to detect that atomic mode-setting cursors are _not shown_, see https://bugs.kde.org/show_bug.cgi?id=479002 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479002] Wayland atomic mode-setting cursors not shown on vmwgfx driver
https://bugs.kde.org/show_bug.cgi?id=479002 --- Comment #1 from Stefan Hoffmeister --- Note that for atomic mode-setting and "hardware" cursors to work on the VMware vmwgfx driver, a kernel patch is required to prevent kernel oopses, see https://bugs.kde.org/show_bug.cgi?id=478308 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479002] Wayland atomic mode-setting cursors not shown on vmwgfx driver
https://bugs.kde.org/show_bug.cgi?id=479002 Stefan Hoffmeister changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=478487 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478487] VMware Workstation + atomic mode-settings needs KWIN_FORCE_SW_CURSOR=1
https://bugs.kde.org/show_bug.cgi?id=478487 Stefan Hoffmeister changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=479002 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478487] VMware Workstation + atomic mode-settings needs KWIN_FORCE_SW_CURSOR=1
https://bugs.kde.org/show_bug.cgi?id=478487 --- Comment #4 from Stefan Hoffmeister --- I am currently digging into cursors in general, have already reached out in the matter of drmCloseBufferHandle (and the TTM/GEM mess) - and have received a response from Zack Rusin of VMware / Broadcom, see https://lore.kernel.org/all/cabqx2qpkewdhe6xaaucafh7qwva06xj8bfqrmpqtkm61x-y...@mail.gmail.com/ Once I understand more about "the cursor situation in KDE on top of vmwgfx", I'll follow up on this. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 478301] Log spam "drmPrimeHandleToFD() failed: No such file or directory" (Wayland, virtualization)
https://bugs.kde.org/show_bug.cgi?id=478301 --- Comment #2 from Stefan Hoffmeister --- The root cause of this is a combination of factors that hit with kwin running in "legacy mode" (this is the default right now due to driver detection and workarounds applied), on the DRM backend: Upon starting the Wayland compositor, output management adds outputs (WaylandCompositor::addOutput). In there, events are connected to handle workspace geometry changes and changes to the cursor (updateCursorLayer, moveCursorLayer). Lambda updateCursorLayer is responsible for handling cursor "content" change. It does that by trying to render a hardware cursor first, and, if that fails, then rendering a fallback. On vmwgfx as of kernel 6.7.0-rc5, trying to render a hardware cursor will *always* fail with "drmPrimeHandleToFD() failed" (and more log messages), and updating the cursor will always enter the fallback path. This causes the log spam. There is a way to disable the attempt to perform hardware cursor rendering: configure environment variable "KWIN_FORCE_SW_CURSOR=1" to enter the (software-based cursor rendering) fallback path immediately. This stops the logspam. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479154] New: Cursor does not scale with output scale (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479154 Bug ID: 479154 Summary: Cursor does not scale with output scale (Wayland, Plasma 6) Classification: Plasma Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-drm Assignee: kwin-bugs-n...@kde.org Reporter: stefan.hoffmeis...@econos.de Target Milestone: --- SUMMARY When changing the scale of an output, all aspect of the cursor should scale as well, together with the change. Right now, no scaling appears to take place in a pure Wayland, Plasma 6 beta2+, KDE stack (i.e. this defect here is not about Xwayland) STEPS TO REPRODUCE 1. log in 2. "Display Properties" -> set scale to 3 == 300% 3. Apply OBSERVED RESULT * Output itself is now scaled, but cursor remains at the previous scale - typically too small. * Cursor hotspot / hitbox is difficult to spot, it does not match where one expects it to be EXPECTED RESULT * cursor is scaled according to output scale * cursor hotspot / hitbox matches with what is on screen A good way to see all this is to run on a high-resolution screen with a very _integral_ scale factor (i.e. 3). This is also not about fractional scaling. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479154] Cursor does not scale with output scale (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479154 Stefan Hoffmeister changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #2 from Stefan Hoffmeister --- Indeed, a virtual machine, vmwgfx of VMware, with ``` # Force atomic mode-setting export KWIN_DRM_NO_AMS=0 # Force software cursors export KWIN_FORCE_SW_CURSOR=1 ``` So, I suspect, the software cursor path might be it? I will get to the vmwgfx GEM / GBM part next week++, but for quite some more time I expect to have to run with software cursors forced on. Sorry that I keep forgetting to provide the environment details! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479154] Cursor does not scale with output scale (Wayland, Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479154 --- Comment #3 from Stefan Hoffmeister --- Created attachment 164561 --> https://bugs.kde.org/attachment.cgi?id=164561&action=edit Screenshot shows correct rendering, but that's not what is shown Funny enough, taking a screenshot (with Spectacle) shows _correct_ rendering - but that screenshot does not reflect what I see on screen. On screen I do not see the large cursor, but the small (unscaled?) cursor. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] New: Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293
Bug ID: 479293
Summary: Multi-monitor Wayland surface does not extend to the
left (Plasma 6)
Classification: Plasma
Product: kwin
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-drm
Assignee: kwin-bugs-n...@kde.org
Reporter: stefan.hoffmeis...@econos.de
Target Milestone: ---
SUMMARY
In a Wayland multi-monitor setup where the non-primary screen is to the _left_
of the primary screen ("extend to the left"), the content is overlapped into
the primary screen.
In ASCII art, for
* left non-primary == 2.5K resolution
* primary == 4K resolution
this looks like
```
+-++
| ||
|-+|
| |
| |
+--|
```
Extending to the right works as expected. This also holds true for a triple
monitor setup, where one screen extends to the left and one screen extends to
the right of the primary screen.
"Display Configuration" shows the intended (correct) layout.
This may be an artefact of running KDE Plasma 6 b2+ (git master) under VMware
Workstation / vmwgfx with `export KWIN_DRM_NO_AMS=0`
STEPS TO REPRODUCE
1. create a multi-monitor setup
2. "physically" place at least one screen to the left of the primary screen
3. use "Display Configuration" to assert that physical left screen is logically
placed to extend the primary screen to the left (i.e. vertically aligned at the
top, offset to the left by resolution of secondary screen)
OBSERVED RESULT
Left screen overlaps primary screen as in ASCII art diagram above.
EXPECTED RESULT
Left screen extends desktop to the left.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #1 from Stefan Hoffmeister --- Created attachment 164616 --> https://bugs.kde.org/attachment.cgi?id=164616&action=edit drm_info in broken state (left-extend not working) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #2 from Stefan Hoffmeister --- Created attachment 164617 --> https://bugs.kde.org/attachment.cgi?id=164617&action=edit drm_info in working state (right-extend working well) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #3 from Stefan Hoffmeister --- Attached drm_info dumps where VMware Workstation adds the monitor "to the left" and "to the right", respectively, where KDE Desktop Configuration matches the extend intent exactly * left-extend == 2.5k screen physically (and mapped through host) to the left * right-extend == 3k laptop screen physically (and mapped through the host) to the right Center screen is always the 4k screen. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #4 from Stefan Hoffmeister --- FWIW, and possibly a separate challenge: Take the working "extend to the right" setup from above and move the secondary screen to _extend to the bottom_. This does not render correctly, either (fair enough - see above). Do note that the mouse cursor now moves "in an unnatural fashion" - it feels as if some unsuitable mouse acceleration profile is being applied. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #5 from Stefan Hoffmeister --- No difference in behaviour with KWIN_DRM_NO_AMS _not_ set - right now (on my kernel) this implies no atomic mode-setting. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #6 from Stefan Hoffmeister --- The matching Fedora Rawhide (40) GNOME setup, which runs in legacy mode (no atomic mode-setting) exposes the exact same behavior as KDE Plasma 6 b2+ (git master) on Wayland. To that extent, there may be a commonality to the multi-monitor Wayland driving of GNOME and KDE Plasma 6 on Fedora Rawhide (40). Additional data point: I also tried KDE Plasma 5.27.10 in an X11 session on Arch Linux, with the same virtual graphics "hardware" setup and with legacy mode setting. In that X11 environment, the screens both left-extend and right-extend correctly for rendering (this was also working previously on F39, do not have this infra at the moment). Note that that the KDE X11 setup has challenges in cursor to (virtual) screen mapping though - but those can be fixed by running a script that uses kscreen-doctor to "re-layout" the screens in a different sequence (cf https://github.com/vmware/open-vm-tools/issues/484#issuecomment-1703922094. So, in theory, given the above, one could argue that Wayland KDE Plasma 6 has regressed relative to X11 KDE Plasma 5.27.10. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #7 from Stefan Hoffmeister --- Created attachment 164618 --> https://bugs.kde.org/attachment.cgi?id=164618&action=edit X11 5.27 left-extend working -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #8 from Stefan Hoffmeister --- Created attachment 164619 --> https://bugs.kde.org/attachment.cgi?id=164619&action=edit drm_info with legacy mode setting in broken state (left-extend not working) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 479293] Multi-monitor Wayland surface does not extend to the left (Plasma 6)
https://bugs.kde.org/show_bug.cgi?id=479293 --- Comment #9 from Stefan Hoffmeister --- Created attachment 164620 --> https://bugs.kde.org/attachment.cgi?id=164620&action=edit Left 6.0 Wayland (broken) <-> Right X11 5.27 (working) Attached a screenshot which shows the material difference(s) between the working X11 setup on Plasma 5.27 and the equivalent non-working Wayland setup on Plasma 6 b2+. Fundamentally, * on X11 (right side), there is one backing framebuffer with size 6400x2160 covering both active planes (with offsetting via the SRC_X property) * on Wayland (left side), there are two distinct framebuffers, one for each plane, each of the "right size", and each at SRC_X == 0. -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 478309] Pipwire format negotiation fails on Wayland with NVIDIA GPU and 545 drivers
https://bugs.kde.org/show_bug.cgi?id=478309 Stefan Hoffmeister changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #11 from Stefan Hoffmeister --- Alas, on my vmwgfx driver (see my initial report), the problem persists. I just ran a fresh kdesrc-build plasma-desktop, the linked commit 5fdfeb18c00ab619d234142d60e922a1f36ae588 is present locally, and I still get the same behaviour as before, where * the preview is empty * there is plenty of log output It might or might not be fixed for NVIDIA - I cannot tell right now. So, the recap, on the exact same (virtual) hardware, * this is faulty for me on Fedora Rawhide (40) with KDE Plasma git master * this works for me on Arch Linux with KDE Plasma 5.27.10 -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 478309] Pipewire format negotiation fails on Wayland with NVIDIA GPU and 545 drivers
https://bugs.kde.org/show_bug.cgi?id=478309 Stefan Hoffmeister changed: What|Removed |Added Summary|Pipwire format negotiation |Pipewire format negotiation |fails on Wayland with |fails on Wayland with |NVIDIA GPU and 545 drivers |NVIDIA GPU and 545 drivers -- You are receiving this mail because: You are watching all bug changes.
[KPipeWire] [Bug 478309] Pipewire format negotiation fails on Wayland with NVIDIA GPU and 545 drivers
https://bugs.kde.org/show_bug.cgi?id=478309 --- Comment #12 from Stefan Hoffmeister --- To reconfirm my challenge on vmwgfx, this is the log output with KDE Plasma 6 from git master (kdesrc-build plasma-desktop) with the commit included --- ``` Jan 05 08:59:58 fedora kwin_wayland[1829]: kwin_core: authorized "/home/stefan/kde/usr/bin/plasmashell" "zkde_screencast_unstable_v1" Jan 05 08:59:58 fedora pipewire[1826]: pw.context: params Spa:Enum:ParamId:EnumFormat: 0:0 Invalid argument (input format (no more input formats)) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Object: size 160, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 2 (Spa:Enum:MediaType:video) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 1 (Spa:Enum:MediaSubtype:raw) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 7 (Spa:Enum:VideoFormat:RGBx) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 40 8 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle 1x1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle 1x1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle -1x-1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:modifier (131074), flags 0008 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Long 72057594037927935 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Object: size 136, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 2 (Spa:Enum:MediaType:video) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 1 (Spa:Enum:MediaSubtype:raw) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 7 (Spa:Enum:VideoFormat:RGBx) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 40 8 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle 1x1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle 1x1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle -1x-1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: params Spa:Enum:ParamId:EnumFormat: 1:0 Invalid argument (output format (no more input formats)) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Object: size 272, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:EnumFormat (3) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 2 (Spa:Enum:MediaType:video) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Id 1 (Spa:Enum:MediaSubtype:raw) Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:size (131075), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Rectangle 1280x728 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:framerate (131076), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Fraction 0/1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:maxFramerate (131077), flags Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Choice: type Spa:Enum:Choice:Range, flags 40 8 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Fraction 60/1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Fraction 1/1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Fraction 60/1 Jan 05 08:59:58 fedora pipewire[1826]: pw.context: Prop: key Spa:Pod:Object:Param:Format:Video:format (131073), flags Ja
