Image on screen freezes but mouse remains to be movable

I updated to openSuse 42.2 a short while ago. Since then many games randomly freeze and I can’t do anything except moving the mouse. In addition, the music is still playing and when I click a button in the game with the mouse I hear that the button was clicked. That means that the system is still responding but I can’t see any reaction on screen except the mouse movement. The only way for me to get back control is to shutdown the computer by pressing the powerbutton (which results in an ordinary shutdown). I also can press ctrl+alt+f11 and get a terminal but in the end I need to restart my computer.
I already searched the web but did not find any solution. Has anyone experienced a similar behaviour and solved the issue somehow.

I don’t know if it is related to this issue but when I use my graphics card with glxgears using

DRI_PRIME=1 glxgears

results in and empty black rectangle. To see the cogs I must either hit shift+alt+f12 or resize the window. So it might be a driver issue. I actually use the open source radeon and intel drivers that are shipped with the vanilla leap 42.2.

I would highly appreciate if anyone can at least narrow down the issue and help me. If you need any log files or outputs please let me know and I can add them to the thread.

Best regards,

My system:
openSUSE 42.2 (KDE)
Kernel 4.4.49-16-default
Acer Notebook
Intel Core i5-4200U
AMD Radeon HD8750M

I think looking at X server logs and systemd journal should allow to narrow down the problem.
Don’t remember how to check Xserver logs but for the journal it’s easy. The easiest way would be to run :

journalctl -f

The command above allows to look at the logs “in real time”.
In that console session to which you can switch when the freeze occurs.
Immediately after the freeze switch to that console and look for anything with ERROR. If you will not be able to spot any errors there or it rolls to fast here are some pointers on browsing through the journal:

Based on the Arch guide for example you could use :

journalctl -f -p err..alert

To just see errors and alerts.

Hi glistwan,
thanks for the quick reply. However the journalctl shows no relevant errors (only HP-systray and HP-upgrade). I also can’t find any useful information in the Xorg.0.log file. It seems like the system didn’t even recognised that the Display is “locked up”. I found something on the Arch website and can at least narrow down my problem to one of the following two cases:

  • Mouse moves, and cursor still changes when moving over window borders. This is usually a bug in the window manager’s state machine where it doesn’t let go of a grab in the X server.
  • Mouse moves, but cursor does not change. This is usually the X server being stuck far away from the dispatch loop (position updates happen asynchronously, but glyph updates do not), either waiting on the kernel or in an infinite loop. The X server will probably print a message in the log about the event queue overflowing when this happens; this is not the bug, it is merely the symptom.

Since the games run in full-screen I cant tell if the mouse cursor would change if I move them over another window. Any further ideas?

Interesting problem but I’m not sure I can help further. I was hoping for some GPU related bug but mouse cursors I know nothing about :slight_smile: The only other thing I can think of is can’t you alt+tab or press any keys to somehow get out of the full screen?

One other thought is since it didn’t happen on 42.2 the main difference is probably the kernel version. You may want to try a different kernel and see if the problem is present as well.
The easiest way would be to install the kernel from this repo:

You can easily revert this change if it doesn’t help. Having said that if it were kernel related I would expect to see at least some errors in the journal.

Hi glistwan,
unfortunately I can’t get out of the full-screen using alt-tab. The only way I found so far was to restart the PC. However, I made another weird observation. If I disable the kwin composite effects using with shift+alt+f12 I haven’t seen any lockups so far. I will also try another kernel over the weekend and see what happens.

Thanks for your time and best regards.

… and???

Did this solve your problem???

I have no more such problems, since I changed Compositor Module from OpenGl 2.0 to XRender.

Just wanted to say I can confirm this, and the issue has also been discussed in my other thread. Note that desktop effects are not the exclusive cause: The exact same freeze happens to me too, and it will take place with desktop effects completely disabled… that and some games trigger it. Also I suggest a “zypper dup” and a restart: There were hundreds of new packages updated today, including xorg-x11-server and xf86-video-ati… still testing to see how they affect the problem if at all.

You run TW not Leap this thread is about leap do not use zypper dup if you use leap use zypper up

Oh, I missed that one detail… sure in that case. It’s weird however, granted the exact same issue was only introduced about two weeks ago for me in Tumbleweed, whereas 42.2 is much older. Unless this is an update in both Tumbleweed and Leap?

Hi Fraser_Bell and all,

sorry that I haven’t posted the result. Unfortunately, installing a newer kernel showed no improvement (I only get more warnings on startup). I actually think that the bug is somehow related with the interplay of my dedicated AMD graphics card (HD8750M) and the intel i5 graphic unit (it is a muxless system which caused some problems before). Since I am fine with deactivating the effects (i dont see much differences anyway) the problem is at least not that urgent to dive deeper into the issue at the moment. However, if someone finds a solution I would be glad to test it.

Best regards.

I know this is about Leap and not Tumbleweed. But the latest packages fixed the freezes for me in TW, roughly a week ago. I believe either x11 or llvm were the culprit, as both were updated in the snapshot that brought the fix… Mesa was not, whereas numerous updates to the Kernel had no effect either until that point.