After 959a1eaf1c15a691141f1b0dc53757fe9b6e9b13 is the first bad commit commit 959a1eaf1c15a691141f1b0dc53757fe9b6e9b13 Author: Dave Airlie <airlied@redhat.com> Date: Fri Jun 4 11:09:46 2010 +1000 composite: use config notify hook to do pixmap resize. i can see corrupted windows with fbdev driver and e16 1.0.2 WM/compositor. full bisect result: ---------------- 959a1eaf1c15a691141f1b0dc53757fe9b6e9b13 is the first bad commit commit 959a1eaf1c15a691141f1b0dc53757fe9b6e9b13 Author: Dave Airlie <airlied@redhat.com> Date: Fri Jun 4 11:09:46 2010 +1000 composite: use config notify hook to do pixmap resize. Since reallocating the backing pixmap can fail, we need to try and do it before any other side effects of reconfiguring the window happen. This changes the ConfigNotify hook to return status, and moves the composite window reconfiguration wrappers to ConfigNotify. They all basically did the same thing, so we can drop the MoveWindow, ResizeWindow, ChangeBorderWidth wrappers, and allow ConfigNotify to do all the work. If reallocation fails we fail before we send any confiureNotify events, or enter the area we can't recover from. The only place we now enforce 32k limits are in EXA/UXA/fb, so drivers that don't use this should probably deal with it in their pixmap allocate if they don't already. This also breaks ABI, so we need an alternate fix for older servers, working on the X server makes me realise why I'm a kernel hacker. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com> :040000 040000 c9566220acea620ecb80402028e4435fa7d07ead a95979fe48f5c6ae58981647270cb12900610a81 M composite :040000 040000 b3d578a4ace90f20e2348f7a3d82254d4463ea83 ad4875747969b87cbe6229206919725244a4b67f M dix :040000 040000 0269478c902be265446636922d4996829c0a1cd6 0d07b0087277b0991d83943ae0048ed5b24dd681 M hw :040000 040000 49c82f6e4c707a7935a183f40843e2bfc14dbb9d 78d17f17d3f2238c31de01f885f6279792f39f7f M include
Created attachment 36132 [details] Example of corruption
cc:ing Dave.
The commit in question changes the driver ABI. Did you rebuild the fbdev driver against the 'broken' xserver tree?
(In reply to comment #3) > The commit in question changes the driver ABI. Did you rebuild the fbdev driver > against the 'broken' xserver tree? Yes, with simple make.
Just tried another driver, nouveau + xserver master (a41d6e9bffbe56cfa1c3b84388a3d9f5a982f1a9 Merge: 7e8f100 f4190fe Author: Keith Packard <keithp@keithp.com> Date: Fri Jun 11 10:08:13 2010 -0700 Merge remote branch 'dottedmag/for-keithp' ). Corruption still here, but i guess this bug appear only with e16's compositing, i can't see it with xcompmgr (but xcompmgr fails to draw shadows, tried it only as attempt to narrow bug down) X/fbdev still stops at: [ 116.792] (II) Initializing built-in extension COMPOSITE [ 116.792] (II) Initializing built-in extension DAMAGE (and nothing more), but this is separate problem ....
okay I've installed e16 on F13 and am having no luck reproducing this even on fbdev. can you give me some ideas of the e16 composite/shadow/eterm background settings/theme etc, you are using.
and as usual 5 mins later I find something, shading/unshading windows seems to lead to it happening.
Created attachment 36396 [details] [review] attempted fix.
(In reply to comment #8) > Created an attachment (id=36396) [details] > attempted fix. Fixed issue for me
Fixed in 82d41ada993d8cbdcdfea878d1a5b031afe4e593
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.