At random points but really rearly (OpenGL?) applications are not redrawn anymore. This happens for me for chromium and OpenGL games. Executing kwin_x11 --replace solves the issue. Reproducible: Sometimes Steps to Reproduce: hard to reproduce because it just happens KWin is set to use OpenGL 3.1 through EGL. Also Full scene repaints are used for Tearing prevention.
please give a try glx again. It's the better maintained option on the X11 platform.
> Also Full scene repaints are used for Tearing prevention. Can you please attach the output of "es2_info"?
see also bug #338150
(In reply to Thomas Lübking from comment #2) > > Also Full scene repaints are used for Tearing prevention. > Can you please attach the output of "es2_info"? I am still usin OpenGL, not OpenGLES. EGL_VERSION: 1.4 (DRI2) EGL_VENDOR: Mesa Project EGL_EXTENSIONS: EGL_MESA_drm_image, EGL_MESA_configless_context, EGL_WL_bind_wayland_display, EGL_KHR_image_base, EGL_KHR_image_pixmap, EGL_KHR_image, EGL_KHR_get_all_proc_addresses, EGL_KHR_gl_texture_2D_image, EGL_KHR_gl_texture_cubemap_image, EGL_KHR_gl_renderbuffer_image, EGL_KHR_surfaceless_context, EGL_KHR_create_context, EGL_NOK_swap_region, EGL_NOK_texture_from_pixmap, EGL_CHROMIUM_sync_control, EGL_EXT_create_context_robustness, EGL_EXT_image_dma_buf_import, EGL_NV_post_sub_buffer EGL_CLIENT_APIS: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 GL_VERSION: OpenGL ES 3.0 Mesa 10.5.0-devel (git-21a280f) GL_RENDERER: Mesa DRI Intel(R) Haswell Mobile GL_EXTENSIONS: GL_EXT_blend_minmax, GL_EXT_multi_draw_arrays, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_compression_dxt1, GL_EXT_texture_format_BGRA8888, GL_OES_compressed_ETC1_RGB8_texture, GL_OES_depth24, GL_OES_element_index_uint, GL_OES_fbo_render_mipmap, GL_OES_mapbuffer, GL_OES_rgb8_rgba8, GL_OES_standard_derivatives, GL_OES_stencil8, GL_OES_texture_3D, GL_OES_texture_npot, GL_OES_EGL_image, GL_OES_depth_texture, GL_OES_packed_depth_stencil, GL_EXT_texture_type_2_10_10_10_REV, GL_OES_get_program_binary, GL_APPLE_texture_max_level, GL_EXT_discard_framebuffer, GL_EXT_read_format_bgra, GL_NV_fbo_color_attachments, GL_OES_EGL_image_external, GL_OES_vertex_array_object, GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, GL_EXT_texture_rg, GL_EXT_unpack_subimage, GL_NV_draw_buffers, GL_NV_read_buffer, GL_EXT_map_buffer_range, GL_OES_depth_texture_cube_map, GL_OES_surfaceless_context, GL_EXT_color_buffer_float, GL_EXT_separate_shader_objects, GL_EXT_shader_integer_mix, GL_KHR_context_flush_control
(In reply to Martin Gräßlin from comment #1) > please give a try glx again. It's the better maintained option on the X11 > platform. "Shouldn't" be GLX replaced by EGL anyway? I will try out GLX for a time, because the same bug happend again today. But after switching to GLX, the desktop wasn't usable anymore so I had to change config and restart kwin from tty.(In reply to Martin Gräßlin from comment #3) > see also bug #338150 I can't see any glitches which may result because of using EGL. There are some bad window redraws sometimes, but I think they also happen with GLX. I think I have to restart X before I can use GLX again.
The bad redraws are in the kwin window switcher, but for some reasons I cannot use the GLX backend, because nothing gets redrawn and the loginmanager background is still there (after login). I even rebootet my system and it still doesn't work with GLX.
> "Shouldn't" be GLX replaced by EGL anyway? I consider it unlikely that EGL on X11 will be a viable option before we do the switch to Wayland. E.g. all drivers need to support it (still not the case with the blobs).
yeah, allthough nvidia is moving forward slowly. Anyway, for some reasons GLX doesn't work for me allthough I have no problems with other GLX based applications.
(In reply to kde from comment #5) > (In reply to Martin Gräßlin from comment #1) > > please give a try glx again. It's the better maintained option on the X11 > > platform. > > "Shouldn't" be GLX replaced by EGL anyway? I will try out GLX for a time, > because the same bug happend again today. But after switching to GLX, the > desktop wasn't usable anymore so I had to change config and restart kwin > from tty.(In reply to Martin Gräßlin from comment #3) EGL does not have feature parity with GLX, and it doesn't appear that anyone is working on adding the missing features.
I have this problem, too. KF5 and KWin versions: master from sometime today Rendering backend: OpenGL 2.0 OpenGL interface: GLX Tearing prevention (vsync): Automatic Driver: NVIDIA binary blob, version 340.65 (latest that is supported for my GPU) Distribution: Arch Linux
(In reply to Lasse Liehu from comment #10) > I have this problem, too. Perhaps. Perhaps not. Notice that the original bug is about a) issues on EGL (which is so far not supported by the nvidia blob) b) OpenGL clients (chromium/games) specifically Does at least the "other opengl applications do not repaint" pattern hold for the problem you observe? If not: a) please file a new bug b) attach the output of "qdbus org.kde.KWin /KWin supportInformation" (w/ running compositor) there c) elaborate on your observations (ie. what stalls repaint - some windows or entire scene, permanently or temporarily, whether there's a pattern like "everytime i change the virtual desktop", etc.) Also please when this happens, move to VT1 and run export DISPLAY=:0 nvidia-smi | tee ~/.nvidia.smi and attach that output as well @Karol Your *GLX* issue might be bug #342582 (depending on when it started exactly)
Oh, sorry. I'll file a new bug the next time it occurs. Thanks.
(In reply to Thomas Lübking from comment #11) > @Karol > Your *GLX* issue might be bug #342582 (depending on when it started exactly) Yeah, sounds like it. Thanks for the reference
So this bug also happens for me with GLX today and this time I had only yakuake in the foreground. Maybe it is totally unrelated to pure OpenGL applications.
I am now using kwin-5.1.95 and since then the bug didn't happen again. I will close this for now.
so this bug happens again with bioshock infinite (allthough the program has other issues as well) kwin-5.2.1 mesa-git-827da84 xf86-video-intel-2.99.917
> mesa-git-827da84 Ensured it's not caused by the MESA checkout de toujours?
okay, since 5.2.95 it happens more than twice a day :/
okay, I think I found a pretty easy way to somehow trigger it pretty often. Running the arm android emulator with native OpenGLES enabled and doing some other OpenGL seems to trigger it really often and with really weird side effects: Sometimes an OpenGL application only gets redrawn in the area of the android emulator and sometimes most parts of the android emulator are "stuck" between two frames where only some minor areas are getting redrawn. Restarting kwin helps with the problems. this happens also with the GLX backend.
does KWIN_EXPLICIT_SYNC=0 kwin_x11 --replace & seem to prevent it?
I also get hangs with that set
This might be bug #338150 as well, please try to enable dri3
I am always on dri3
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Changing the status of the bug report as per comment 24