Bug 235195

Summary: x11/plasma5-plasma: Windows and menus do not redraw after upgrade
Product: Ports & Packages Reporter: Peter C B Henderson <peter.henderson>
Component: Individual Port(s)Assignee: kde
Status: Open ---    
Severity: Affects Only Me CC: ahicks, grahamperrin, kde, tcberner, tijl, x11
Priority: --- Keywords: needs-qa, regression
Version: LatestFlags: koobs: maintainer-feedback? (kde)
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
Installed ports on 12/01/19, before the update.
none
List of installed ports on 19/01/19, after upgrade.
none
./local/share/sddm/xorg-session.log for the initially empty guest account. none

Description Peter C B Henderson 2019-01-25 11:30:12 UTC
Created attachment 201391 [details]
Installed ports on 12/01/19, before the update.

After I updated /usr/ports at 15:05 18/01/19 UTC, and then ran "portupgrade -a", my desktop stopped working properly.  Initially, after logging in, all seems more or less normal (see below for a fuller description), but after a number of window operations, the desktop menus are transparent with only the outline shadowing visible and application menus are just black.  Any new windows that are opened show only the frame, their interior being black.  At this point the only option is to log on through the console and manually kill the running kdeinit5 process.
Comment 1 Peter C B Henderson 2019-01-25 12:01:08 UTC
Created attachment 201392 [details]
List of installed ports on 19/01/19, after upgrade.

Continuing my previous submission.

When I initially log in, some strange behavior occurs.  For example, using firefox, when the bookmarks button is clicked, nothing appears until after the mouse is moved down, at which point only the icons on the left of the menu show up.  The rest of the menu items only appear as the mouse is moved down over them.  Generally, firefox then goes to the selected web pages, but it is not long until menus only appear as black and the main window ends up black as well.

Some History:

I reinstalled all my ports a few weeks ago so as to start using kde5.  I have attached the output of "pkg version" both before, upgrade-a-19012.ver, and after, upgrade-a190119.ver, the offending upgrade. Looking in the svn repository, I see plasma5 was updated, r490472, between these two upgrades of the ports tree.

Later I upgraded the OS after a security email.  The output "uname -a" is:

FreeBSD hydrogen 11.2-RELEASE-p8 FreeBSD 11.2-RELEASE-p8 #0 r343007: Mon Jan 14 17:07:39 AEDT 2019     root@hydrogen:/usr/obj/usr/src/sys/GENERIC  amd64

I login from sddm.

I set up an new user account with no files and logged in to it.  The same behavior occurred.  So it is not my personal set-up that causes the problem.

I have also tried rebuilding everything. Again, this failed to fix the problem.
Comment 2 Peter C B Henderson 2019-01-25 12:09:12 UTC
Created attachment 201393 [details]
./local/share/sddm/xorg-session.log for the initially empty guest account.

Have attached .local/share/sddm/xorg-session.log for a session using the initially empty guest account.

Note, the messages near the end, starting from:
"Unexpected response from KInit (response = 34417092560).
startkde: Could not start ksmserver. Check your installation."
are a result of manually killing the running kdeinit5 process to escape back to the login prompt.
Comment 3 Graham Perrin 2019-01-26 14:22:11 UTC
System Settings ▶ Display and Monitor ▶ Compositor

Which rendering backend is preferred?

Also: 

pciconf -lv | grep -B 3 -A 1 display

kldstat
Comment 4 Peter C B Henderson 2019-01-27 00:09:23 UTC
"System Settings ▶ Display and Monitor ▶ Compositor" shows
"OpenGL 2.0" as the "Rendering backend".

Also,
"compositing on startup" is enabled, the "Animation speed" is set to halfway between "Instant" and "Very slow", the "Scale method" is "Accurate", "Tearing prevention("vsync")" is "Automatic", "Keep window thumbnails" is "Only for Shown Windows" and "Allow applications to block compositing" is enabled.

Note, these were all automatically set.  I haven't changed any of them.

"pciconf -lv | grep -B 3 -A 1 display" outputs
"
vgapci0@pci0:1:0:0:     class=0x030000 card=0x83541043 chip=0x0a6510de rev=0xa2 hdr=0x00
    vendor     = 'NVIDIA Corporation'
    device     = 'GT218 [GeForce 210]'
    class      = display
    subclass   = VGA
"

"kldstat" outputs
"
Id Refs Address            Size     Name
 1   17 0xffffffff80200000 20647c8  kernel
 2    1 0xffffffff82266000 381130   zfs.ko
 3    2 0xffffffff825e8000 a380     opensolaris.ko
 4    1 0xffffffff82821000 12c8     ulpt.ko
 5    1 0xffffffff82823000 20198    ipfw.ko
 6    1 0xffffffff82844000 6fc4     tmpfs.ko
"
Comment 5 Peter C B Henderson 2019-02-03 03:25:47 UTC
Here is a description of more observed behaviour which has no dependency non-KDE applications, except that applications have been automatically found and inserted into the application menus.

I created a test account with no configuration files.  I then logged in from sddm. Then I opened a Konsole window via Applications>System>Terminal.

One peculiar behaviour is the when I try to move a window into the bottom right-hand corner, it seems to hit an obstacle and starts to reduce in size.  Also, the redrawing stops working properly, so that there are partial redraws of the window as I move it around, without erasures of previously drawn fragments.  Everything returns to normal once I move the window away from the forbidden region.

Note, there is no problem moving the window left-to-right or top-to-bottom, provided the window doesn't encroach into the region near the bottom right-hand corner.

It is difficult to determine the exact size of this forbidden region, but it seems to be the same size as a small message window, there is nothing to indicate there is anything there.

After closing and creating a number of Konsole windows, an instance appears where only the title bar and frame is visible, the body of the window being transparent.  At this point, kde menus become transparent, and hence unusable, with only the shading of their frame visible.  I then have to kill the running Kdeinit process manually from the console.  A message window, with its body blacked out, appears on the kde desktop.  On closing this window, the desktop session closes and the sddm welcome screen appears.  After which I can log in again.
Comment 6 Tobias C. Berner freebsd_committer 2019-02-03 07:32:18 UTC
Moin moin

Are you using x11/nvidia-driver?


Mfg Tobias
Comment 7 Peter C B Henderson 2019-02-03 09:52:33 UTC
My bad.

I was not using any nvidia drivers.  I've just installed them and everythings behaving fine now.  At least so far.

However, that doesn't explain why I started having problems after updating everything on 18/01/19.

Note, I did consider the possibility that things were very slow, but it seemed no longer how long I waited for the desktop menus to be filled in, nothing happened.  They stayed stubbornly transparent.
Comment 8 Jan Beich freebsd_committer 2019-02-03 12:32:44 UTC
IIRC, xf86-video-scfb and xf86-video-vesa use software rendering by default: llvmpipe from mesa-dri. Recent mesa-dri 18.1.9 -> 18.3.2 could regress llvmpipe. Try rolling back to 18.2.8, then 18.1.9.
Comment 9 Peter C B Henderson 2019-02-05 01:03:48 UTC
As stated in my previous comment (2019-02-03 09:52:33 UTC), installing the nvidia driver fixed the problem.

Nevertheless, to help identify what caused it in the first place I started the regression of mesa-dri, as suggested by Jan Beich (2019-02-03 12:32:44 UTC).

The first step was to delete the nvidia packages I had installed, i.e. nvidia-driver-340-340.107_3, nvidia-settings-415.25 and nvidia-xconfig-415.25.  I rebooted and then checked to see if the problem had returned.  To my surprise, everything seemed to work as it should.  Application menus worked normally.  The strange forbidden region of the screen (see my comment 2019-02-03 03:25:47 UTC) didn't manifest itself.

To see if I could recreate the problem, I then removed the linux compatibility packages installed when I installed the nvidia driver, i.e. linux-c6-expat-2.0.1_5, linux-c6-fontconfig-2.8.0_3, linux-c6-xorg-libs-7.4_10 and linux_base-c6-6.10.  Again, I rebooted to see if the problem had returned.  Again, everything was, and still is, working normally.  Note, these were the only linux compatibility packages on my system.

As a result, I'd like to know if there is still any point in regressing mesa-dri as suggested by Jan Beich?  I'm actually not sure if I can perform this regression.

FYI, I have included a list of all the upgrades I have done since this problem appeared.  None of them in themselves fixed the problem, but they may have some bearing on why it has not reappeared.

apache-openoffice-4.1.6_3 -> apache-openoffice-4.1.6_4
bash-5.0_2 -> bash-5.0.2
binutils-2.30_7,1 -> binutils-2.31.1_1,1
ca_root_nss-3.41 -> ca_root_nss-3.42
cmake-3.13.2 -> cmake-3.13.3
droid-fonts-ttf-20131024_3 -> droid-fonts-ttf-20131024_4
emacs-26.1_4,3 -> emacs-26.1_5,3
firefox-64.0.2_1,1 -> firefox-65.0_1,1
gnutls-3.6.5_1 -> gnutls-3.6.6
gsed-4.2.2_2 -> gsed-4.7
harfbuzz-2.3.0 -> harfbuzz-2.3.1
harfbuzz-icu-2.3.0 -> harfbuzz-icu-2.3.1
hunspell-1.6.2_2 -> hunspell-1.7.0
java-zoneinfo-2018.g -> java-zoneinfo-2018.i
kf5-sonnet-5.54.0_1 -> kf5-sonnet-5.54.0_2
krdc-18.12.1_1 -> krdc-18.12.1_2
  -> libchk-1.10.3 (newly installed package)
libedit-3.1.20170329_2,1 -> libedit-3.1.20181209_2,1
libgit2-0.27.7 -> libgit2-0.27.8
libgpg-error-1.34 -> libgpg-error-1.35
libinput-1.11.3_1 -> libinput-1.12.6
libnghttp2-1.35.1 -> libnghttp2-1.36.0
libssh-0.8.4 -> libssh-0.8.6
libssh2-1.8.0,3 -> libssh2-1.8.0_1,3
libuv-1.24.1 -> libuv-1.25.0
libva-2.3.0_5 -> libva-2.4.0
libvncserver-0.9.11_2 -> libvncserver-0.9.12_1
libxkbcommon-0.8.0 -> libxkbcommon-0.8.0_1
mysql56-client-5.6.42_1 -> mysql56-client-5.6.43
mysql56-server-5.6.42_2 -> mysql56-server-5.6.43
mythes-1.2.4_5 -> mythes-1.2.4_6
node-11.6.0 -> node-11.8.0
nss-3.41_1 -> nss-3.42
okular-18.12.1_1 -> okular-18.12.1_2
p11-kit-0.23.14 -> p11-kit-0.23.15
pciids-20181228 -> pciids-20190120
pkgconf-1.5.4,1 -> pkgconf-1.6.0,1
plasma5-kdeplasma-addons-5.14.5_1 -> plasma5-kdeplasma-addons-5.14.5_2
py27-beaker-1.10.0 -> py27-beaker-1.10.0_1
py27-pytz-2018.7,1 -> py27-pytz-2018.9,1
py27-requests-2.18.4_1 -> py27-requests-2.21.0
py27-setuptools-40.6.2 -> py27-setuptools-40.6.3
py27-setuptools_scm-1.17.0 -> py27-setuptools_scm-3.1.0
py36-setuptools-40.6.2 -> py36-setuptools-40.6.3
qt5-virtualkeyboard-5.12.0_1 -> qt5-virtualkeyboard-5.12.0_2
re2-20180901_1 -> re2-20190101
rust-cbindgen-0.6.8_1 -> rust-cbindgen-0.7.1
sane-backends-1.0.27_4 -> sane-backends-1.0.27_5
sudo-1.8.27 -> sudo-1.8.27_1
thunderbird-60.4.0_2 -> thunderbird-60.5.0
tradcpp-0.5.2 -> tradcpp-0.5.3
wayland-1.16.0 -> wayland-1.16.0_1
webp-1.0.1_1 -> webp-1.0.2
zsh-5.6.2_1 -> zsh-5.7_1
Comment 10 Alan Hicks 2019-02-07 13:38:05 UTC
I can confirm I have the same issue with, after a while, menus not drawing other than outline and new windows are black.

pciconf -lv | grep -B 3 -A 1 display

vgapci0@pci0:0:2:0:     class=0x030000 card=0x3048103c chip=0x2e128086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '4 Series Chipset Integrated Graphics Controller'
    class      = display
    subclass   = VGA
vgapci1@pci0:0:2:1:     class=0x038000 card=0x3048103c chip=0x2e138086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '4 Series Chipset Integrated Graphics Controller'
    class      = display
none0@pci0:0:3:0:       class=0x078000 card=0x3048103c chip=0x2e148086 rev=0x03 hdr=0x00

Settings/System Settings/Display and Monitor
Rendering backend:
- OpenGL 2.0 and 3.1 both exhibit this bug;
- XRender appears to work ok.