Created attachment 78948 [details] Screenshot of the issue This is a follow-up to bug 59703. On a fresh install of Fedora 19, there are rendering issues of the title bar in kde/kwin. This is only if the Qt Engine is "Native" ("Raster" works well). I have different issues depending on whether the desktop effects are enabled or not, most visible being without desktop effects. $ glxinfo |grep render direct rendering: Yes OpenGL renderer string: Gallium 0.4 on AMD CAPE VERDE GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_fog_distance, kernel 3.9.0 Mesa 9.1.1 ati ddx 7.1.0 glamor 0.5.0 libdrm 2.4.44 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750] [1002:683f]
I found an even bigger issue with the native backend: after a while X starts eating my cpu. At the moment you just can't use radeonsi with KDE (see https://bugs.freedesktop.org/show_bug.cgi?id=69341 for the issue with Raster backend) which is too bad :(
This is still occuring with xf86-video-ati from git as of 25 march 2013. Talking with glisse on IRC commit http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=0c921edf0162fed616cea9d02e168b719243bcd2 fixed a similar problem with gnome but did not help with kde. I am using an up to date arch install with xf86-video-ati git and mesa 10.2 git kernel 3.14-rc8 on an r7 260x The title bars of kde windows are transparent when they should be gray. Context menus from title bars (kde or other window types) are quasi transparent (some parts are transparent, some are corrupt).
Created attachment 96372 [details] titlebar and context menu corruption non kde windows are usually okay. sometimes parts of their title bars become transparent but eventually an update (eg moving the window, uncovering it etc) fixes this.
There are two aspects to this bug. One is a corrupted titlebar. This can be bypassed using Settings/System Settings/Desktop Effects/Advanced and setting 'Composting type' to something other than xrender (one of the opengl selections). The other aspect is that the context menus of titlebars are corrupt. To bypass this problem, using the same menu path given above, change the 'Qt graphics system' to Raster. This uses the cpu instead of the gpu for some window decorations and gets around the driver buglets.
Does this still happen with glamor from the xserver tree instead of from the standalone glamor tree?
glamor is built from git://git.freedesktop.org/git/xorg/driver/glamor here. Is this the tree to which you are referring to or is this the standalone tree. If its not the one you would like tested, what is the url?
Is it possible to just build glamor from: git://git.freedesktop.org/git/xorg/xserver or am I better off building the complete xserver 1.15.99.902 ?
You have to build the whole xserver tree to try glamor from it. You'll also need to use the xf86-video-ati Git master branch built against that xserver tree.
Thanks about what I though. The arch aur package xorg-server-dev builds 1.15.99.902 however modifing the configure to include --enable-glamor generates the following: Making all in glamor make[1]: Entering directory '/tmp/yaourt-tmp-ed/aur-xorg-server-dev/src/xorg-server-1.15.99.902/glamor' CC glamor.lo In file included from glamor.c:36:0: glamor_priv.h:55:28: fatal error: glamor_program.h: No such file or directory #include "glamor_program.h" ^ compilation terminated. Makefile:722: recipe for target 'glamor.lo' failed make[1]: *** [glamor.lo] Error 1 make[1]: Leaving directory '/tmp/yaourt-tmp-ed/aur-xorg-server-dev/src/xorg-server-1.15.99.902/glamor' If its not something stupid missing in the configure or prereqs, where should this be reported?
(In reply to comment #9) > In file included from glamor.c:36:0: > glamor_priv.h:55:28: fatal error: glamor_program.h: No such file or directory I submitted a fix for this: http://lists.x.org/archives/xorg-devel/2014-April/041832.html Meanwhile, can you build or at least get the missing headers from Git?
It's building fine with missing headers (from git) added
From git with your patch applied it builds and the context menus work correctly. However 1.15.99.902 is buggy (this is not unexpected :-/ ). I cannot start it with startx but need to use kdm... (XF86OpenConsole gets a permission denied; Xorg and /usr/bin have correct permissions). While the context menus are okay text is corrupted and unreadable in chromium's search box and its popup selection (where you select a url that you have used previously). Its also unreadable in gkrellm.
Good new is that I have packages that I can rebuild easily from git when additional tests are needed. Let me know if you want a new bug(s?) opened on the chromium and gkrellm issues
(In reply to comment #12) > While the context menus are okay text is corrupted and unreadable in > chromium's search box and its popup selection (where you select a url that > you have used previously). Its also unreadable in gkrellm. If my xf86-video-ati Git patches from http://lists.x.org/archives/xorg-driver-ati/2014-April/026140.html and http://lists.x.org/archives/xorg-driver-ati/2014-April/026139.html don't help for this, building xserver from the glamor-server branch of git://anongit.freedesktop.org/~keithp/xserver might.
With the two video-ati fixes applied on top of git the text corruption is gone - nice call! You can add my tested by to these if you want. Tested by: Ed Tomlinson <edtoml@gmail.com> I still cannot start X via startx and need to use kdm which, from experience, eventually gets me into trouble. Any ideas on this?
fyi. The new xserver runs the uniengine tropical benchmark about 20% faster than 1.15 (see https://bugs.freedesktop.org/show_bug.cgi?id=75992 for details)
(In reply to comment #15) > I still cannot start X via startx and need to use kdm which, from > experience, eventually gets me into trouble. Any ideas on this? No, please file a separate bug report for this. Resolving this report, as the original problem seems fixed in xserver master.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.