Odd window behavious / invisible windows

[StonedSidney]

I have a new install of LM 19.1 on a new Lenovo laptop with 8GB of RAM and intel graphics. I have applied the recommended updates via GUI, that that's the only change.

After running for a while (hours) the problem begins.....

When I open a new app it appears in the taskbar but no window appears for the app. The window that was already on remains on screen but can't be used; it's a ghost. If I alt-tab the switcher appears on top and I can click through the options, but can't switch to another app. Then the switcher graphic remains on top. Sometimes I can activate the underlying window (how? no idea) e.g. Firefox, and I can scroll content etc. but the switcher window remains on top!

There's lots of RAM capacity remaining and TOP shows the CPU is bored with the lack of action, so I think it's a software bug, maybe graphics driver?
uname -r
4.15.0-47-generic

What other info do I need to post?
TIA

[StonedSidney]

Here's a video I made showing the problem in action. Hopefully this makes the problem a bit clearer! It is OK to post links to videos I hope
https://youtu.be/ZwSclTzIqdU

[jimallyn]

Run inxi -Fxz in a terminal and copy/paste the output of that command into your next post here. That will show us what your video system (and other hardware) is, what drives are being used, and other useful information like that.

[StonedSidney]

Here you go. Neat command I haven't seen before.

Code: Select all

System:    Host: sid-Lenovo-ideapad-330S-14IKB Kernel: 4.15.0-47-generic x86_64 bits: 64 compiler: gcc v: 7.3.0 
           Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19.1 Tessa base: Ubuntu 18.04 bionic 
Machine:   Type: Laptop System: LENOVO product: 81F4 v: Lenovo ideapad 330S-14IKB serial: <filter> 
           Mobo: LENOVO model: LNVNB161216 v: SDK0J40709 WIN serial: <filter> UEFI: LENOVO v: 7SCN26WW date: 10/26/2018 
Battery:   ID-1: BAT0 charge: 28.0 Wh condition: 29.2/30.0 Wh (97%) model: LENOVO BASE-BAT status: Unknown 
CPU:       Topology: Quad Core model: Intel Core i7-8550U bits: 64 type: MT MCP arch: Kaby Lake rev: A L2 cache: 8192 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 31872 
           Speed: 800 MHz min/max: 400/4000 MHz Core speeds (MHz): 1: 793 2: 739 3: 763 4: 796 5: 787 6: 800 7: 800 8: 800 
Graphics:  Device-1: Intel UHD Graphics 620 vendor: Lenovo driver: i915 v: kernel bus ID: 00:02.0 
           Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa resolution: 1440x810~60Hz 
           OpenGL: renderer: Mesa DRI Intel UHD Graphics 620 (Kabylake GT2) v: 4.5 Mesa 18.2.8 direct render: Yes 
Audio:     Device-1: Intel Sunrise Point-LP HD Audio vendor: Lenovo driver: snd_hda_intel v: kernel bus ID: 00:1f.3 
           Sound Server: ALSA v: k4.15.0-47-generic 
Network:   Device-1: Intel Dual Band Wireless-AC 3165 Plus Bluetooth driver: iwlwifi v: kernel port: 3040 bus ID: 01:00.0 
           IF: wlp1s0 state: up mac: <filter> 
Drives:    Local Storage: total: 476.94 GiB used: 23.83 GiB (5.0%) 
           ID-1: /dev/nvme0n1 vendor: Western Digital model: PC SN520 SDAPMUW-512G-1101 size: 476.94 GiB 
Partition: ID-1: / size: 326.51 GiB used: 23.80 GiB (7.3%) fs: ext4 dev: /dev/nvme0n1p5 
Sensors:   System Temperatures: cpu: 30.0 C mobo: 0.0 C 
           Fan Speeds (RPM): N/A 
Info:      Processes: 372 Uptime: 4d 21h 30m Memory: 7.70 GiB used: 4.83 GiB (62.7%) Init: systemd runlevel: 5 Compilers: 
           gcc: 7.3.0 Shell: bash v: 4.4.19 inxi: 3.0.27

[StonedSidney]

OK I have narrowed the problem down to user switching making the problem reproducible. Sometimes after switching users we are asked to authenticate (see image). If I click cancel, the dialogue box remains on the screen but it isn't active and any new windows/dialogues don't appear, but they are the top app and they're active responding to keypresses.

Thankfully I have learned that Ctrl-Alt-Esc resets the desktop and gets things working again. Or we can enter the password to authenticate. Both options are just really annoying after a while. Getting another laptop for the OH might work, but that's a bit expensive

Anyone got any ideas? Can anyone even reproduce the problem?

Authentication message.png

[Viking-bg]

Hi,

I have the exact same problem as you explained in the video. I also realized it happens after a user switch.

I found out that (sometimes) I can input the user password and that will unlock the screen (although the screen is not on the screensaver - just like in your video). I thought the problem/bug must lie with the unlock feature of the screensaver, i.e. the screensaver is active although it shows the "active window". I thought the problem could perhaps be solved by selecting another screen saver, but then I noticed that Mint 19.1 does not offer various screen savers anymore. The default is the only screensaver, without the option to change it.

I still think the bug is somewhere with the screensaver behaviour in Mint 19.1, but seeing that I do not know anything about programming I cannot really troubleshoot it.

Today this issue caused the most bizarre behaviour on my pc. I was logged into the pc. At one stage, after the screensaver was on, my wife woke the pc and switched to her profile. Then she started watching a youtube video. Suddenly the pc froze, but the video kept on playing. I typed in my wife's user password and the session switched back to my profile, (but the screen was still frozen), and then the youtube video that I was watching on my profile (prior to my wife using the pc) started playing! So, youtube was simultaneously playing on two different user profiles at the same time! We could see no video (the screen was still frozen, but both videos' sound was playing.

Again, I think it has something to do with the screensaver that was changed in Mint 19.

I have been using Mint for 5 years (17.3 was the best), but this is causing real problems for us. I will have to go to a more stable distro soon because this is also a work pc for my wife, and we cannot afford such irrational pc behaviour.

[smurphos]

I can reproduce this behaviour - by waking a machine from suspend with a logged in user and then switching users from that users lock screen. The second user will normally need to restart cinnamon with Ctr-Alt-Esc after logging in to avoid weirdness. It's been an issue I've noted since 18.x IIRC - but I think it's more likely to be a symptom of systemd managing suspend since 18.x

[StonedSidney]

Thanks guys for confirming you can recreate the prob, and confirming I'm not alone!

Not sure anyone is listening though Same as Wifi hard-blocks and Thumbnails on file upload being too small. Old problems

I'm gonna try Cinnamon on Ubuntu but I love Mint and hope these things get fixed.