GNOME Bugzilla – Bug 650994
extremely slow when second monitor is plugged
Last modified: 2021-07-05 14:15:45 UTC
Hi, I am testing gnome-shell from Debian experimental repository (3.0.1-1), and when I plug an external monitor it is detected and all, and after some instants gnome-shell sets it up an the "extra screen". But then gnome-shell starts to consume a lot of CPU, and the desktop becomes unusable. xrandr output: ============================================================================= $ xrandr Screen 0: minimum 320 x 200, current 1280 x 768, maximum 4096 x 4096 LVDS1 connected 1280x768+0+0 (normal left inverted right x axis y axis) 305mm x 183mm 1280x768 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 connected (normal left inverted right x axis y axis) 1280x1024 60.0 + 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 TV1 unknown connection (normal left inverted right x axis y axis) 848x480 30.0 + 640x480 30.0 + 1024x768 30.0 800x600 30.0 ============================================================================= the TV1 output is not actually connected, so I don't known whether the fact it is not been reported as disconnected may cause a problem. Please let me known of any other information I can provide, or how could I debug this.
I guess this should also be useful: $ lspci | grep 915 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
i915 has a maximum texture size of 2048x2048. Since both of your outputs side by side exceed 2048 horizontally you get software fallback which is too slow for gnome-shell.
Should't gnome-shell refuse to automatically use the second monitor with that configuration, then? If I could at least use the desktop after plugging the monitor, I would go into system preferences and configure the monitors so that one is "on top" of the other (and thus less than 2048 pixels in both directions). Would it make send for gnome-shell to do that automatically? It could: 1) rearrange the screen positions to have an area smaller than 2048x2048 2) do not use the largest possible resolution on the extra monitor to avoid getting a screen bigger than 2048x2048 3) if none of the above is possible, warn the user and NOT turn the second monitor on automatically.
It should. Right now it doesn't.
Oh right now I understand! It was working well when my two screens were on top of the others. And when I splitted them it started getting very slow with a lots of artifacts. Is there a way to force that behavior without plugging a screen at first? 00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge (rev 02) 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller (rev 02) 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller (rev 02)
I can confirm this behaviour on 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller using gnome-shell_3.0.2-8+b1 from Debian testing. It always "locks up" if i try to configure a setup with my builtin display panel (1024x600) at the left or right side of my external display (1280x1024). It works as expected with classic mode. Putting builtin above or below external isn't a solution since i want the xrandr setup represent my physical setup. Also, putting external above/below internal has other issues which make external screen space unusable anyways. If this is a hardware constraint (which i doubt) only a fallback to classic mode would be the right course of action IMHO.
*** Bug 661407 has been marked as a duplicate of this bug. ***
I can confirm the problem for Gnome 3.3.x for Ubuntu Oneiric (experimental PPA from ricotz) and for Gnome 3.2 at Ubuntu Oneiric repositories. The problem still persists and I can't use Gnome in notebook presentations and projectors. I think this is not hardware problem: Gnome do not works in many resolutions (the screen becomes black or like a TV channel without connection) and with the resolution who works this bug here happens. I have KDE installed here (I use it to my presentations) and all resolutions works good for me and no performance problem. My EEEPC 1005-HA works perfectily with 1900x1280 using KDE. Gnome don't... I will try post some output here soon, but I can confirm the problem for new versions of Gnome for now.
(In reply to comment #8) > I can confirm the problem for Gnome 3.3.x for Ubuntu Oneiric (experimental PPA > from ricotz) and for Gnome 3.2 at Ubuntu Oneiric repositories. > > The problem still persists and I can't use Gnome in notebook presentations and > projectors. > > I think this is not hardware problem: Gnome do not works in many resolutions > (the screen becomes black or like a TV channel without connection) and with the > resolution who works this bug here happens. I have KDE installed here (I use it > to my presentations) and all resolutions works good for me and no performance > problem. My EEEPC 1005-HA works perfectily with 1900x1280 using KDE. Gnome > don't... The problem is that you lose hardware acceleration, which is needed by the Shell. I don't know what KDE does in that case, but it's possible that it's able to work reasonably without acceleration. Jasper, you said the Shell should detect this problem. You mean it should choose a screen arrangement that fits in the maximum texture size? Shouldn't also the Display control center applet notice the problem when you try to set the configuration to something that wouldn't work (asking so that we file a bug there too)?
(In reply to comment #9) > (In reply to comment #8) > > I can confirm the problem for Gnome 3.3.x for Ubuntu Oneiric (experimental PPA > > from ricotz) and for Gnome 3.2 at Ubuntu Oneiric repositories. > > > > The problem still persists and I can't use Gnome in notebook presentations and > > projectors. > > > > I think this is not hardware problem: Gnome do not works in many resolutions > > (the screen becomes black or like a TV channel without connection) and with the > > resolution who works this bug here happens. I have KDE installed here (I use it > > to my presentations) and all resolutions works good for me and no performance > > problem. My EEEPC 1005-HA works perfectily with 1900x1280 using KDE. Gnome > > don't... > The problem is that you lose hardware acceleration, which is needed by the > Shell. I don't know what KDE does in that case, but it's possible that it's > able to work reasonably without acceleration. > > > Jasper, you said the Shell should detect this problem. You mean it should > choose a screen arrangement that fits in the maximum texture size? Shouldn't > also the Display control center applet notice the problem when you try to set > the configuration to something that wouldn't work (asking so that we file a bug > there too)? I just meant "don't use the monitor" - at the time, I was thinking that we would pop up a notification, recognizing that the monitor was plugged in, but we're not going to use it because it would make things slow. Of course, now that ajax is working on making the Shell run reasonably under llvmpipe, we could do that instead.
(In reply to comment #10) > I just meant "don't use the monitor" - at the time, I was thinking that we > would pop up a notification, recognizing that the monitor was plugged in, but > we're not going to use it because it would make things slow. It would also be nice to choose an arrangement that doesn't exceed the maximum texture size: e.g. stacked monitors instead of side-to-side, if that works around the problem; or cloned monitors. A dialog could just be used to notice the user of this choice. > Of course, now that ajax is working on making the Shell run reasonably under > llvmpipe, we could do that instead. Yeah, if we're guaranteed it works OK, that would be great. But if it's still a little slow, maybe it would be good to tell the user that a different screen arrangement would be more efficient.
It's at least driver related (xorg-video-intel): http://www.thinkwiki.org/wiki/Xorg_RandR_1.2#the_Virtual_screen A shame that fallback mode isn't really supported, only as long as it's deemed necessary and will be phased out. Guess i'll have to look elsewhere for a useful DE.
(In reply to comment #12) > A shame that fallback mode isn't really supported, only as long as it's deemed > necessary and will be phased out. Guess i'll have to look elsewhere for a > useful DE. For now fallback mode is still present, and by the time it's removed, we will have good software acceleration support with llvmpipe so that it will no longer be an issue. So you probably won't need to change DE.
The problem still not solved yet at Gnome 3.4.1. This test is at Ubuntu Precise Pangolin (12.04). Now we can plug in the second screen and use it, but Gnome-shell still using 100% of the CPU and the system is really slow. This is the top output: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2910 saulo 20 0 789m 70m 37m R 100 3.5 16:07.25 gnome-shell And here the xrandr output: $ xrandr Screen 0: minimum 320 x 200, current 2304 x 1024, maximum 4096 x 4096 LVDS1 connected 1024x600+0+0 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.0*+ 65.0 800x600 60.3 56.2 640x480 59.9 VGA1 connected 1280x1024+1024+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1
I have a little more information about my last comment. The 100% CPU use happens only when both screens are actived. I disabled my laptop screen and the CPU use runs from 1% to 21%. The virtual memory use it's about 152MB to 750MB yet. (top output) With the screens listed at last comment, both actived yet: - Mirror both screens solves the problem too; - Use both at same resolution lowers the CPU use; - If you try put both at same resolution and try back the external screen to any other resolution, the screen show only lines and it's needed wait the timeout time to gnome reset the last configuration. Since I tried change the resolution, I'm unable to test both screens with different resolutions.
Created attachment 228047 [details] gnome-shell strace output
This bug still on 3.6.x! Why still unconfirmed? This bug is annoying even to report! Unfortunately, I have no enought space to install all debug packages in my netbook, and no other machine to test, but I'm attaching all reports I got here using 3.6.1 gnome version. Since the first report, gnome is better, we can use a second monitor alone with gnome, but still impossible to use both monitors plugged in! Just plug the cable at gnome it's annoying! The processor use goes to 100%! I needed more than 1.5 hours only to come here to report, then I ask somebody more to help with a better machine. xrandr output: Screen 0: minimum 320 x 200, current 2933 x 1080, maximum 4096 x 4096 LVDS1 connected 1024x600+1909+0 (normal left inverted right x axis y axis) 220mm x 129mm 1024x600 60.0*+ 65.0 800x600 60.3 56.2 640x480 59.9 VGA1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm 1920x1080 60.0*+ 1680x1050 74.9 60.0 1680x945 60.0 1400x1050 74.9 60.0 1600x900 60.0 1280x1024 75.0 70.0 60.0 1440x900 75.0 59.9 1280x960 60.0 1366x768 60.0 1360x768 60.0 1280x800 74.9 59.8 1152x864 75.0 1280x768 74.9 59.9 1024x768 75.1 70.1 60.0 1024x576 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 848x480 60.0 640x480 72.8 75.0 60.0 top output: top - 15:16:02 up 4:13, 3 users, load average: 1,12, 1,19, 1,04 Tarefas: 182 total, 2 running, 179 sleeping, 0 stopped, 1 zombie %Cpu(s): 50,8 us, 0,8 sy, 0,0 ni, 47,2 id, 0,7 wa, 0,0 hi, 0,5 si, 0,0 st KiB Mem: 2056908 total, 1805540 used, 251368 free, 161636 buffers KiB Swap: 2147324 total, 47104 used, 2100220 free, 984236 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 21233 saulo 20 0 576m 78m 41m R 99,1 3,9 7:48.83 gnome-shell 855 messageb 20 0 4412 2120 960 S 0,7 0,1 0:38.37 dbus-daemon 21632 saulo 20 0 4892 1504 1044 R 0,7 0,1 0:01.40 top 10 root 20 0 0 0 0 S 0,3 0,0 0:05.50 ksoftirqd/1 889 syslog 20 0 31072 1104 924 S 0,3 0,1 0:07.54 rsyslogd 951 root 20 0 33348 4868 3944 S 0,3 0,2 0:16.82 NetworkManager 2770 oracle 20 0 656m 29m 26m S 0,3 1,5 0:05.71 oracle 20940 root 20 0 52456 12m 4628 S 0,3 0,6 0:11.47 Xorg 21060 root 20 0 0 0 0 S 0,3 0,0 0:00.80 kworker/0:1 21424 saulo 20 0 748m 28m 21m S 0,3 1,4 0:11.68 gnome-control-c 21694 root 20 0 8084 2320 1956 S 0,3 0,1 0:00.01 nm-dispatcher.a 1 root 20 0 3732 1984 1296 S 0,0 0,1 0:02.40 init 2 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kthreadd 3 root 20 0 0 0 0 S 0,0 0,0 0:05.97 ksoftirqd/0 6 root rt 0 0 0 0 S 0,0 0,0 0:00.29 migration/0 7 root rt 0 0 0 0 S 0,0 0,0 0:00.20 watchdog/0 8 root rt 0 0 0 0 S 0,0 0,0 0:00.26 migration/1 11 root rt 0 0 0 0 S 0,0 0,0 0:00.16 watchdog/1 12 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 cpuset 13 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 khelper 14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 kdevtmpfs 15 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 netns 17 root 20 0 0 0 0 S 0,0 0,0 0:00.02 sync_supers 18 root 20 0 0 0 0 S 0,0 0,0 0:00.00 bdi-default 19 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kintegrityd 20 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kblockd 21 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ata_sff 22 root 20 0 0 0 0 S 0,0 0,0 0:00.00 khubd 23 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 md 26 root 20 0 0 0 0 S 0,0 0,0 0:00.02 khungtaskd 27 root 20 0 0 0 0 S 0,0 0,0 0:04.99 kswapd0 28 root 25 5 0 0 0 S 0,0 0,0 0:00.00 ksmd 29 root 39 19 0 0 0 S 0,0 0,0 0:00.00 khugepaged 30 root 20 0 0 0 0 S 0,0 0,0 0:00.00 fsnotify_mark 31 root 20 0 0 0 0 S 0,0 0,0 0:00.00 ecryptfs-kthrea 32 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 crypto 41 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kthrotld 44 root 20 0 0 0 0 S 0,0 0,0 0:00.00 scsi_eh_0 45 root 20 0 0 0 0 S 0,0 0,0 0:00.00 scsi_eh_1 46 root 20 0 0 0 0 S 0,0 0,0 0:00.00 scsi_eh_2 47 root 20 0 0 0 0 S 0,0 0,0 0:00.00 scsi_eh_3 52 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 binder 72 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 deferwq 73 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 charger_manager 74 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 devfreq_wq 75 root 20 0 0 0 0 S 0,0 0,0 0:07.32 kworker/1:2 258 root 20 0 0 0 0 S 0,0 0,0 0:02.32 jbd2/sda5-8 259 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 ext4-dio-unwrit 277 root 20 0 0 0 0 S 0,0 0,0 0:01.77 flush-8:0 353 root 20 0 2820 744 628 S 0,0 0,0 0:00.62 upstart-udev-br 355 root 20 0 3240 1016 768 S 0,0 0,0 0:00.39 udevd 429 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 cfg80211 451 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kpsmoused 477 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 hd-audio0 542 root 20 0 4896 684 524 S 0,0 0,0 0:00.01 mount.ntfs-3g 586 root 20 0 4920 708 528 S 0,0 0,0 0:00.10 mount.ntfs-3g 608 root 20 0 2816 500 412 S 0,0 0,0 0:00.08 upstart-socket- 620 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 led_workqueue 621 root 20 0 7044 3176 796 S 0,0 0,2 0:26.53 mount.ntfs-3g I'm attaching an strace output, but I'm not certainly if it's what you need, but here is. A valgrind output is here too, but I have no enought space to install debug packages, and I can't help with this at the moment, but is here, if helps...
Created attachment 228048 [details] The valgrind output Used: valgrind --leak-check=full --track-origind=yes --show-reachable=yes --log-file=gnome-shell-valgring.log -- gnome-shell --replace
Why this still unconfirmed? What kind of information is needed to continue with this report? Stills on Gnome 3.6.
We don't differentiate between the UNCONFIRMED and NEW statuses, and are working on getting it removed.
Is this bug still being addressed? With Debian stable using gnome 3.14 I experience slow video output on my Thinkpad T60. I use a T60 so I can use libreboot. Relevant lspci info: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) xrandr info when connected via VGA: Screen 0: minimum 320 x 200, current 2760 x 1050, maximum 4096 x 4096 LVDS1 connected primary 1400x1050+0+0 (normal left inverted right x axis y axis) 286mm x 214mm 1400x1050 60.02*+ 59.98 50.00 1280x1024 60.02 1280x960 60.00 1360x768 59.80 59.96 1152x864 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 60.00 59.94 VGA1 connected 1360x768+1400+0 (normal left inverted right x axis y axis) 1102mm x 620mm 1360x768 60.02*+ 1024x768 75.08 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 640x480 75.00 72.81 66.67 60.00 720x400 70.08 DVI1 disconnected (normal left inverted right x axis y axis) TV1 unknown connection (normal left inverted right x axis y axis) 848x480 59.94 + 640x480 59.94 + 1024x768 59.94 800x600 59.94
Bug persists in GNOME 3.18.
Still persists in GNOME 3.20.2. I'm guessing the GNOME project does not want to treat software fallback as a possible solution? If this is true, I don't think this problem can be solved. To my understanding, this makes GNOME problematic with all currently supported libreboot laptops. A simple work around that I have been using is use a DE like MATE whenever needing to do presentations, and switch the display entirely to an external display when needing to use a bigger monitor. This gets around the slowness with one monitor, but using more than one monitor is definitely out of the question.
Still persists on Fedora 24 with Gnome 3.20 and 25 with Gnome 3.22 on NVidia 375 driver with Quadro M2000M. It is like everything works ok after booting, however if there is any changes to the monitor setup or if screens are turned off, this problem is striggered. So that should narrow this issue down considerably. As productivity increasing with more monitors, this is a critial issue to me and I am sure a lot of others. Is there some kind of diagnostics tool I can install to help out?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.