Bug 414719 - plasma unusable (incredibly slow) in 2 monitor config with nouveau on a laptop
Summary: plasma unusable (incredibly slow) in 2 monitor config with nouveau on a laptop
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.17.3
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-01 12:46 UTC by slartibart70
Modified: 2021-04-09 04:33 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
glxinfo (31.44 KB, text/plain)
2019-12-01 15:56 UTC, slartibart70
Details
glxinfo (42.97 KB, text/plain)
2020-01-28 15:49 UTC, waldauf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description slartibart70 2019-12-01 12:46:27 UTC
I use an older T430 lenovo laptop with integrated nvidia graphics (optimus).
I am using nouveau driver for nvidia mainly because the docking stations connectors for an external monitor are wired to nvidia.
Setup is as follows:

up to fc30/plasma 5.16.4 (using zawertun copr repo)
Laptop screen is used for booting, when logging in into plasma the main display is transferred to the second monitor connected via displayPort (at the docking station).
The laptop screen is then disabled (and lid can be closed), effectively working only on the big second screen.
All is working like a charm.

-----

since upgrade to plasma 5.17.3:
The plasma desktop on the 2nd screen is in above configuration completely unusable. Mouse clicks (e.g. right click-menu) appear only after several(!) seconds, kicker is unusable, window moving is unusable.

----

My experiments so far:
- enable both displays, laptop screen and ext. Monitor, expand the desktop e.g. to the left.
Works as a charm, 2nd. monitor still being the 'primary/default' one.

- enable both displays, but have the laptop screen (which has a smaller resolution than the 2nd ext. monitor) coordinates put over the 2nd screen coordinates (so both show the same contents, bothe starting at upper left corner 0,0).
still works ok.
NOW: close the laptop lid.
Result: plasma on 2nd monitor is unusable and slow as hell.
Open lid again: ... all is fine
This is independent of the power settings (when laptop lid is closed to: nothing/sleep/...)
Alternatively: have 2nd. ext. monitor defined as primary, but disable the laptop screen (in display and monitor/display config), click apply: plasma is unusable. re-enable laptop display again... all is fine.

My configuration for the t430 right now (extending desktop) forces me to keep the laptop lid open, even if i don't use the laptop screen.

lsmod | grep nou
nouveau              2273280  1
mxm_wmi                16384  1 nouveau
ttm                   122880  1 nouveau
i2c_algo_bit           16384  2 i915,nouveau
drm_kms_helper        212992  2 i915,nouveau
drm                   512000  14 drm_kms_helper,i915,ttm,nouveau
wmi                    36864  3 wmi_bmof,mxm_wmi,nouveau
video                  49152  3 thinkpad_acpi,i915,nouveau

uname -a
Linux t430 5.3.13-200.fc30.x86_64 #1 SMP Mon Nov 25 23:02:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

----

I also did a check on a modern t470 laptop also having nvidia graphics, but here i use the nvidia binary driver and bumblebee / bbswitch.
Main operation is on intel graphics similar to t430.

I did the same tests as with the t430 above, also disabling laptop screen while 2nd monitor is connected but no slowdowns whatsoever are visible.

Any idea how to stop my t430 and plasma from slowing down so bitterly?
Comment 1 slartibart70 2019-12-01 12:51:33 UTC
forgot to mention my experiments with compositor on t430
The slowdown is also independent of openGL 2.0/openGL 3.1/XRender settings
Comment 2 David Edmundson 2019-12-01 12:55:17 UTC
Show me the output of glxinfo
Comment 3 slartibart70 2019-12-01 15:56:52 UTC
Created attachment 124240 [details]
glxinfo

i ran the glxinfo command with extended desktop and open laptop lid, and once when laptop lid was closed (yes, that took me a while ... :-)
But, results of glxinfo are identical
Comment 4 Bug Janitor Service 2019-12-16 04:33:09 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 slartibart70 2019-12-16 06:15:09 UTC
seems i forgot to change status after submitting infos...
Comment 6 waldauf 2020-01-28 15:49:10 UTC
Created attachment 125491 [details]
glxinfo
Comment 7 waldauf 2020-01-28 15:52:28 UTC
I have similar symptoms. But I'm running on the Intel's graphic card. When I connect an external monitor (one or two) to my laptop (HDMI or MiniDP) then my plasmashell gets stuck and I'm not possible to click on whatever with a mouse. The keyboard works alright. A quick win is restart plasmashell or restart SDDM.

Information about system & KDE:
Operating System: Arch Linux 
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.0
Kernel Version: 5.4.15-arch1-1

Packages containing plasma:
extra/plasma-workspace-wallpapers 5.17.5-1
extra/plasma-workspace 5.17.5-2
extra/plasma-sdk 5.17.5-1
extra/plasma-pa 5.17.5-1
extra/plasma-nm 5.17.5-1
extra/plasma-integration 5.17.5-1
extra/plasma-framework 5.66.0-1
extra/plasma-desktop 5.17.5-2

If you need additional problem write me what exactly. In journalclt/dmesg  I didn't find any relevant information. 

Similar bug: https://bugs.kde.org/show_bug.cgi?id=416347
Comment 8 waldauf 2020-01-28 15:55:25 UTC
Now I caught some (hopefully) relevant logs in journalctl:

Jan 28 16:53:06 jenpockej dbus-daemon[964]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.6897' (uid=1000 pid=1398 comm="/usr/lib/firefox/firefox --sm-client-id 10143c8d9d")
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:06 jenpockej systemd[1]: Starting Hostname Service...
Jan 28 16:53:06 jenpockej kwin_x11[1158]: file:///usr/share/kwin/aurorae/MenuButton.qml:22: TypeError: Cannot read property 'closeOnDoubleClickOnMenu' of null
Jan 28 16:53:07 jenpockej dbus-daemon[964]: [system] Successfully activated service 'org.freedesktop.hostname1'
Jan 28 16:53:07 jenpockej systemd[1]: Started Hostname Service.
Jan 28 16:53:08 jenpockej sudo[403769]: pam_unix(sudo:auth): conversation failed
Jan 28 16:53:08 jenpockej sudo[403769]: pam_unix(sudo:auth): auth could not identify password for [waldauf]
Jan 28 16:53:08 jenpockej sudo[403775]: pam_unix(sudo:auth): conversation failed
Jan 28 16:53:08 jenpockej sudo[403775]: pam_unix(sudo:auth): auth could not identify password for [waldauf]
Jan 28 16:53:08 jenpockej kwin_x11[1158]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 29176, resource id: 56627913, major code: 15 (QueryTree), minor code: 0
Jan 28 16:53:08 jenpockej kwin_x11[1158]: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 29181, resource id: 56627913, major code: 18 (ChangeProperty), minor code: 0
Jan 28 16:53:09 jenpockej krusader[1439]: 16:53:09.523-warning default unknown@0 # file not found (unexpected), path= "/tmp/mozilla-temp-805311980"
Comment 9 Nate Graham 2021-03-10 21:54:00 UTC
Does it get any better if yo use the default Breeze decoration rather than an Aurorae one?
Comment 10 Bug Janitor Service 2021-03-25 04:33:54 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 11 Bug Janitor Service 2021-04-09 04:33:40 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!