Version: 4.6 (using KDE 4.6.2) OS: Linux When connecting to a kde session using xdmcp (from another computer), most of the display is reversed vertically (see detailed description and photos below). This make the session unusable. Reproducible: Didn't try Steps to Reproduce: I'm connecting to my computer from another computer using xdmcp. There's no problem with the login, but as soon as the the loading screen appears, the display gets corrupted. Actual Results: What happens is : Every item is reversed vertically, but items are still displayed at their normal position (pannel on the bottom, krunner on top, notifications on bottom right, etc). The inputs are handled normally, meaning to interact with items, I need to click where they should be. No problem with keyboard. The wallpaper is reversed too. Mandatory photos : http://imgur.com/a/TnsPw When taking a screenshot, the screenshot is a reversed vertically from what is seen on the screen (didn't saved the screenshot, I should have). Expected Results: I should see the screen the same way it appears when I log on mu computer. The problem happens with various users, including just created users. This problem doesn't happens with other desktop manager (mwm), based on the wallpaper.
Oups, missed the "Reproducible" part of the form. This always happens when connecting to my computer from the same other computers. I haven't tried other configurations. I'm about to.
This most certainly is a bug in the video drivers, but since I don't know what other components are involved with xdmcp, I am reassigning.
The texture is flipped, resp the texture coords are "wrong". A simple hackaround would be as simple as an effectplugin to glScalef(1,-1,1); but the question is whether this is a bug in the driver/xdmcp or actually part of the xdmcp spec... The GLTexture::render() function contains explicit flipping code, but y_inverted seems to be "false" (and i don't see where it's ever set dynamically or true at all) @georges the problem will go away by suspending composition (shift+alt+f12) and should rather not occur using the xrender backend ("kcmshell4 kwincompositing", advanced tab) Please provide detailed information about the client and server HW and SW versions (esp. GPU/CPU, GPU driver version, -in case you're not using the prop nvidia driver- mesa, xorg & xdmcp versions )
I found the same Problem. I used different Hardware. (radeon and intel driver) Server with kdm and all clients have the same version of Xorg an Co. X.Org X Server 1.9.3 Release Date: 2010-12-13 X Protocol Version 11, Revision 0 Build Operating System: openSUSE SUSE LINUX Current Operating System: Linux server 2.6.37.6-0.5-desktop #1 SMP PREEMPT 2011-04-25 21:48:33 +0200 x86_64
Same problem for me. This with openSUSE_12.1.
can you please in the xdmcp session open a terminal (konsole), run glxinfo| grep -iE '(power|rect)' and post the output? Thanks.
That was quite a challenge as the keyboard events are not processed inside konsole, and all characters are upside down. Anyway here is the output: direct rendering: No GL_EXT_texture_env_dot3, GL_NV_texture_rectangle, GL_NV_vertex_program, GL_ARB_texture_non_power_of_two, GL_EXT_texture_env_combine *** WARNING: Direct Rendering is NOT enabled Without XDMCP (on the computer that serves as server for XDCMP), the output is: direct rendering: Yes GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_EXT_Cg_shader, GL_EXT_depth_bounds_test, GL_EXT_direct_state_access, GL_NV_texture_rectangle, GL_NV_texture_shader, GL_NV_texture_shader2,
I was just able to get a normal rendered display. I was now able to execute the command inside konsole. The glxinfo | grep info remains the same. On stderr I got: Xlib: extension "NV-GLX" missing on display "192.168.x.y:1".
Thanks a lot - does that "keyboard events are not processed inside konsole" mean if you type in konsole you won't get any updates (ie. text written)? I assume the issue is gone if you a) suspend compositing (Shift+Alt+F12) or b) change to the xrender backend in "kcmshell4 kwincompositing"? in case: can you suspend compositing, run "glxgears" and make a snapshot (or just check against normal glxgears whether those are flip/flopped as well)
Hi Thomas, > "keyboard events are not processed inside konsole" > mean if you type in konsole you won't get any updates (ie. text written)? Indeed. When the desktop gets normal orientation (because the compositing is disabled automatically e.g.) konsole accepts keyboard input again. > I assume the issue is gone if you > a) suspend compositing (Shift+Alt+F12) or Yes, this works (ah now I know the famous keys) > b) change to the xrender backend in "kcmshell4 kwincompositing"? Done. After login out and back in again, the orientation of the desktop is still correct. > in case: can you suspend compositing, run "glxgears" and make a snapshot > (or just check against normal glxgears whether those are flip/flopped as > well) I ran glxgears and it is around 58 frames / second on the (xdcmp) remote system. On the system that is used as server for the remote desktop, the number of frames per second is around 1300. The picture shown on the remote desktop and the server desktop is the same. It is not rotated or mirrored on the remote desktop. What is effect of using xrender in contrast to opengl? Which has preference?
Funny: when I change to the opengl backend in "kcmshell4 kwincompositing" the display gets directly mirrored. At this point I just wait and because I don't confirm the change, kde (kwin) falls back it old settings and all is fine again.
The problem is about the opengl implementation - possibly kwin bug and probably the indirect case (thus directly comes with the settings) - there's some branched flipping code in the GL renderer but i don't know at hand whether it's related to indirect rendering. --- XRender doesn't support all effects -but we're trying to shrink that number- mostly because it cannot deal with 4x4 matrices (so there's no frustum) The pro of xrender is that it works for you ;-) Also it has less overhead in transferring the windows into "textures", but i don't know how this impacts on xdmcp
Thanks for the support sofar. Hopefully this can be fixed for opengl, that would be nice.
it would be helpful to get an update of the state with 4.10. The glx backend code changed a little bit and some bugs related to resolving GLX extensions have been fixed. Please also provide the output of (requires at least 4.9) qdbus org.kde.kwin /KWin supportInformation and attach the output of glxinfo
Martin, I just tried, but was not able to connect to the server that should supply the desktop :( For now I did not figure out the reason. Hopefully Thomas, or George can supply you with the requested information.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Hello! Sadly, I don't have the hardware setup, nor the software setup in which the problem was occurring anymore. I won't be able to reproduce.
Thanks for the update!