--0016361e86c05ad957046ad5baf0 Content-Type: multipart/alternative; boundary=0016361e86c05ad944046ad5baee --0016361e86c05ad944046ad5baee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, May 26, 2009 at 3:49 AM, Danny Baumann wrote: > Hi, Hey Danny! =:) Thanks for the reply!! > > 1) When an application requests a topology change via > > _NET_WM_FULLSCREEN_MONITORS, Compiz does honor the topology > > change, but it > > does not refresh any monitor that has changed since the > > last > > _NET_WM_FULLSCREEN_MONITORS topology. If the application > > requests to > > change from fullscreening monitor 1 to cover both monitors > > 1 and 2, the > > window is resized and can still be interacted with, but the > > display still > > shows a frozen image of what was previously on the second > > monitor, for > > example. > > I can not reproduce that using your test program. I have seen a similar > problem on rare occasion, though: Window contents, especially of larger > windows, were stuck at that time and could be recovered only by > unmapping and re-mapping (minimize, shade) them. > Unfortunately I didn't find a good reproduction scenario so far, and I > really don't know what should cause that. > Are you using Nvidia's drivers, by any chance? > Yes, actually, I am. 01:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1) 05:04.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) (II) NVIDIA GLX Module 173.14.18 Mon Mar 2 12:43:12 PST 2009 > Another shot in the dark: You can try playing around with the "Force > synchronization between X and GLX" option in the workarounds plugin. > Perhaps it's just the sort-of-well-known redraw issue caused by race > conditions in the X damage protocol. Hm. Okay, I tried that and it didn't help. If I do an explicit gtk_widget_hide() and then gtk_widget_show() after I do the XSendEvent in the sample program (as attached), then compiz correctly draws the window, but that's not desirable since it causes the window to (obviously) disappear/reappear. > > 2) When a window has fullscreened and used > > _NET_WM_FULLSCREEN_MONITORS, if > > any tooltips are used in that window (as this simple > > application does), > > Compiz will cause the screen to flash repeatedly until the > > user stops > > hovering over the originating widget and the tooltip goes > > away. This can > > be demonstrated in this simple application by hovering over > > the button in > > the window. As an interesting aside, when Compiz causes the > > screen to > > flash, it will refresh the monitors that were previously > > stale from #1 > > above. > > > You want to disable "Unredirect fullscreen windows" (in ccsm it's under > General options). Ubuntu enables it by default (both settings have > problems: enabling it causes the problem you're seeing, disabling it > causes speed loss in fullscreen OpenGL apps, e.g. games). > OOH! *ding ding ding* AWESOME, thanks Danny! Okay, so disabling that fixed not only the tooltip over a fullscreen problem, but it also fixed the first problem I was describing! If I disable "Unredirect fullscreen windows", switching topologies with _NET_WM_FULLSCREEN_MONITORS looks like it works perfectly with Compiz 0.8.2. Is there anything an application can do to detect whether this setting is in effect and warn its users about it? This is going to cause a large amount of community forum posts/bug reports for VMware Workstation/Player, I think. If there's something we can do to be proactive about it, I'd like to do that, but it feels like it may just need to be documented for our Compiz users? Thanks again for your help Danny! You rock! =:) -- -[ Jason 'vanRijn' Kasper // http://movingparts.net ]- -[ KDE PIM Developer // http://www.kde.org ]- -[ bash fun -> :(){ :|:&};: // Numbers 6:22-26 ]- --0016361e86c05ad944046ad5baee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, May 26, 2009 at 3:49 AM, Danny Baumann <= span dir=3D"ltr"><dannybaumann@we= b.de> wrote:
Hi,

Hey Danny! =3D:) Thanks for the reply!!
=A0
=
> =A0 =A0 =A0 =A0 1) When an application requests a topology change via<= br> > =A0 =A0 =A0 =A0 =A0 =A0_NET_WM_FULLSCREEN_MONITORS, Compiz does honor = the topology
> =A0 =A0 =A0 =A0 change, but it
> =A0 =A0 =A0 =A0 =A0 =A0does not refresh any monitor that has changed s= ince the
> =A0 =A0 =A0 =A0 last
> =A0 =A0 =A0 =A0 =A0 =A0_NET_WM_FULLSCREEN_MONITORS topology. If the ap= plication
> =A0 =A0 =A0 =A0 requests to
> =A0 =A0 =A0 =A0 =A0 =A0change from fullscreening monitor 1 to cover bo= th monitors
> =A0 =A0 =A0 =A0 1 and 2, the
> =A0 =A0 =A0 =A0 =A0 =A0window is resized and can still be interacted w= ith, but the
> =A0 =A0 =A0 =A0 display still
> =A0 =A0 =A0 =A0 =A0 =A0shows a frozen image of what was previously on = the second
> =A0 =A0 =A0 =A0 monitor, for
> =A0 =A0 =A0 =A0 =A0 =A0example.

I can not reproduce that using your test program. I have seen a simil= ar
problem on rare occasion, though: Window contents, especially of larger
windows, were stuck at that time and could be recovered only by
unmapping and re-mapping (minimize, shade) them.
Unfortunately I didn't find a good reproduction scenario so far, and I<= br> really don't know what should cause that.
Are you using Nvidia's drivers, by any chance?

Yes, actually, I am.

01:00.0 VGA compatible c= ontroller: nVidia Corporation NV44 [Quadro NVS 285] (rev a1)
05:04.0 VGA= compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1)<= br>
(II) NVIDIA GLX Module=A0 173.14.18=A0 Mon Mar=A0 2 12:43:12 PST 2009=A0
Another shot in the dark: You can try playing around with the "Force synchronization between X and GLX" option in the workarounds plugin. Perhaps it's just the sort-of-well-known redraw issue caused by race conditions in the X damage protocol.

Hm. Okay, I tried= that and it didn't help.

If I do an explicit gtk_widget_hide() = and then gtk_widget_show() after I do the XSendEvent in the sample program = (as attached), then compiz correctly draws the window, but that's not d= esirable since it causes the window to (obviously) disappear/reappear.
=A0
> =A0 =A0 =A0 =A0 2) When a window has fullscreened and used
> =A0 =A0 =A0 =A0 _NET_WM_FULLSCREEN_MONITORS, if
> =A0 =A0 =A0 =A0 =A0 =A0any tooltips are used in that window (as this s= imple
> =A0 =A0 =A0 =A0 application does),
> =A0 =A0 =A0 =A0 =A0 =A0Compiz will cause the screen to flash repeatedl= y until the
> =A0 =A0 =A0 =A0 user stops
> =A0 =A0 =A0 =A0 =A0 =A0hovering over the originating widget and the to= oltip goes
> =A0 =A0 =A0 =A0 away. This can
> =A0 =A0 =A0 =A0 =A0 =A0be demonstrated in this simple application by h= overing over
> =A0 =A0 =A0 =A0 the button in
> =A0 =A0 =A0 =A0 =A0 =A0the window. As an interesting aside, when Compi= z causes the
> =A0 =A0 =A0 =A0 screen to
> =A0 =A0 =A0 =A0 =A0 =A0flash, it will refresh the monitors that were p= reviously
> =A0 =A0 =A0 =A0 stale from #1
> =A0 =A0 =A0 =A0 =A0 =A0above.


You want to disable "Unredirect fullscreen windows" (in= ccsm it's under
General options). Ubuntu enables it by default (both settings have
problems: enabling it causes the problem you're seeing, disabling it causes speed loss in fullscreen OpenGL apps, e.g. games).
<= /div>
OOH! *ding ding ding* AWESOME, thanks Danny! Okay, so disabling th= at fixed not only the tooltip over a fullscreen problem, but it also fixed = the first problem I was describing! If I disable "Unredirect fullscree= n windows", switching topologies with _NET_WM_FULLSCREEN_MONITORS look= s like it works perfectly with Compiz 0.8.2.

Is there anything an application can do to detect whether this setting = is in effect and warn its users about it? This is going to cause a large am= ount of community forum posts/bug reports for VMware Workstation/Player, I = think. If there's something we can do to be proactive about it, I'd= like to do that, but it feels like it may just need to be documented for o= ur Compiz users?

Thanks again for your help Danny! You rock! =3D:)

= --
-[ Jason 'vanRijn' Kasper =A0 =A0// =A0http://movingparts.net ]-
-[ KDE PIM Developer =A0 = =A0 =A0 =A0 // =A0http://www.kde.org =A0= ]-
-[ bash fun -> :(){ :|:&};: =A0// =A0Numbers 6:22-26 ]-
--0016361e86c05ad944046ad5baee-- --0016361e86c05ad957046ad5baf0 Content-Type: text/x-c++src; charset=US-ASCII; name="test_NET_WM_FULLSCREEN_MONITORS-button-clicking.c" Content-Disposition: attachment; filename="test_NET_WM_FULLSCREEN_MONITORS-button-clicking.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fv6zkrh50 I2luY2x1ZGUgPGd0ay9ndGsuaD4KI2luY2x1ZGUgPGdkay9nZGt4Lmg+CiNpbmNsdWRlIDxzdHJp bmcuaD4KCnN0YXRpYyBHdGtXaWRnZXQqIHdpbmRvdzsKc3RhdGljIEd0a1dpZGdldCogYnV0dG9u OwpzdGF0aWMgR3RrV2lkZ2V0KiBsYWJlbDsKc3RhdGljIGd1aW50IHRvcG9sb2d5OwoKc3RhdGlj IGdib29sZWFuIGZ1bGxzY3JlZW4oKQp7CiAgIGd0a193aW5kb3dfZnVsbHNjcmVlbihHVEtfV0lO RE9XKHdpbmRvdykpOwogICByZXR1cm4gRkFMU0U7Cn0KCnN0YXRpYyBnYm9vbGVhbiB1bmZ1bGxz Y3JlZW4oKQp7CiAgIGd0a193aW5kb3dfdW5mdWxsc2NyZWVuKEdUS19XSU5ET1cod2luZG93KSk7 CiAgIHJldHVybiBGQUxTRTsKfQoKc3RhdGljIGdib29sZWFuIHN3aXRjaF9tb25pdG9ycyhncG9p bnRlciBkYXRhKQp7CiAgIHN0YXRpYyBjb25zdCBsb25nIG1vbml0b3JzWzZdWzRdID0gewogICAg ICB7MCwgMCwgMCwgMH0sCiAgICAgIHsxLCAxLCAxLCAxfSwKICAgICAgezAsIDEsIDAsIDB9LAog ICAgICB7MSwgMSwgMCwgMH0sCiAgICAgIHswLCAwLCAwLCAxfSwKICAgICAgezAsIDEsIDAsIDF9 CiAgIH07CgogICBzdGF0aWMgY29uc3QgY2hhciogZGVzY1s2XSA9IHsKICAgICAgICJXaW5kb3cg c2hvdWxkIGJlIGNvdmVyaW5nIGp1c3QgdGhlIGZpcnN0IGhlYWQsIGhlaWdodDogdG9wL2JvdHRv bSBvZiBmaXJzdCBoZWFkXG4iLAogICAgICAgIldpbmRvdyBzaG91bGQgYmUgY292ZXJpbmcganVz dCB0aGUgc2Vjb25kIGhlYWQsIGhlaWdodDogdG9wL2JvdHRvbSBvZiBzZWNvbmQgaGVhZFxuIiwK ICAgICAgICJXaW5kb3cgc2hvdWxkIGJlIGNvdmVyaW5nIGp1c3QgdGhlIGZpcnN0IGhlYWQsIGhl aWdodDogdG9wIG9mIGZpcnN0IGhlYWQsIGJvdHRvbSBvZiBzZWNvbmQgaGVhZFxuIiwKICAgICAg ICJXaW5kb3cgc2hvdWxkIGJlIGNvdmVyaW5nIGp1c3QgdGhlIGZpcnN0IGhlYWQsIGhlaWdodDog dG9wIG9mIHNlY29uZCBoZWFkLCBib3R0b20gb2Ygc2Vjb25kIGhlYWRcbiIsCiAgICAgICAiV2lu ZG93IHNob3VsZCBiZSBjb3ZlcmluZyBib3RoIGhlYWRzIDEgYW5kIDIsIGhlaWdodDogdG9wIGFu ZCBib3R0b20gb2YgZmlyc3QgaGVhZFxuIiwKICAgICAgICJXaW5kb3cgc2hvdWxkIGJlIGNvdmVy aW5nIGJvdGggaGVhZHMgMSBhbmQgMiwgaGVpZ2h0OiB0b3Agb2YgZmlyc3QgaGVhZCwgYm90dG9t IG9mIHNlY29uZCBoZWFkXG4iLAogICB9OwoKICAgZ3VpbnQgaW5kZXggPSBHUE9JTlRFUl9UT19V SU5UKGRhdGEpOwoKICAgZ19kZWJ1ZygiaW5kZXg6ICVkXG4iLCBpbmRleCk7CgogICBpZiAoaW5k ZXggPiA1KSB7CiAgICAgIHVuZnVsbHNjcmVlbigpOwogICAgICBndGtfbGFiZWxfc2V0X3RleHQo R1RLX0xBQkVMKGxhYmVsKSwgIlVuZnVsbHNjcmVlbmVkLiIpOwogICAgICB0b3BvbG9neSA9IDA7 CiAgICAgIHJldHVybiBGQUxTRTsKICAgfSBlbHNlIHsKICAgICAgZnVsbHNjcmVlbigpOwogICAg ICBndGtfbGFiZWxfc2V0X3RleHQoR1RLX0xBQkVMKGxhYmVsKSwgZGVzY1tpbmRleF0pOwogICB9 CgogICBnX2RlYnVnKGRlc2NbaW5kZXhdKTsKCiAgIEdka0Rpc3BsYXkgKmRpc3BsYXkgPSBnZGtf ZGlzcGxheV9nZXRfZGVmYXVsdCgpOwogICBYQ2xpZW50TWVzc2FnZUV2ZW50IHhjbGllbnQ7Cgog ICBtZW1zZXQoJnhjbGllbnQsIDAsIHNpemVvZih4Y2xpZW50KSk7CiAgIHhjbGllbnQudHlwZSA9 IENsaWVudE1lc3NhZ2U7CiAgIHhjbGllbnQud2luZG93ID0gR0RLX1dJTkRPV19YSUQod2luZG93 LT53aW5kb3cpOwogICB4Y2xpZW50Lm1lc3NhZ2VfdHlwZSA9IGdka194MTFfZ2V0X3hhdG9tX2J5 X25hbWVfZm9yX2Rpc3BsYXkoZGlzcGxheSwgIl9ORVRfV01fRlVMTFNDUkVFTl9NT05JVE9SUyIp OwogICB4Y2xpZW50LmZvcm1hdCA9IDMyOwogICB4Y2xpZW50LmRhdGEubFswXSA9IG1vbml0b3Jz W2luZGV4XVswXTsKICAgeGNsaWVudC5kYXRhLmxbMV0gPSBtb25pdG9yc1tpbmRleF1bMV07CiAg IHhjbGllbnQuZGF0YS5sWzJdID0gbW9uaXRvcnNbaW5kZXhdWzJdOwogICB4Y2xpZW50LmRhdGEu bFszXSA9IG1vbml0b3JzW2luZGV4XVszXTsKICAgeGNsaWVudC5kYXRhLmxbNF0gPSAxOwoKICAg WFNlbmRFdmVudChHREtfV0lORE9XX1hESVNQTEFZKHdpbmRvdy0+d2luZG93KSwKICAgICAgICAg ICAgICBHREtfV0lORE9XX1hXSU5ET1coZ2RrX2dldF9kZWZhdWx0X3Jvb3Rfd2luZG93KCkpLAog ICAgICAgICAgICAgIEZhbHNlLAogICAgICAgICAgICAgIFN1YnN0cnVjdHVyZVJlZGlyZWN0TWFz ayB8IFN1YnN0cnVjdHVyZU5vdGlmeU1hc2ssCiAgICAgICAgICAgICAgKFhFdmVudCAqKSAmeGNs aWVudCk7CgogICAvLyB0aGlzIGRvZXMgd29yaywgYnV0IGNhdXNlcyBvdXIgd2luZG93IHRvIGRp c2FwcGVhciBhbmQgdGhlbiByZWFwcGVhciwKICAgLy8gd2hpY2ggaXMgbm90IGRlc2lyYWJsZQog ICBndGtfd2lkZ2V0X2hpZGUod2luZG93KTsKICAgZ3RrX3dpZGdldF9zaG93KHdpbmRvdyk7CiAg IC8vIHRoaXMgZG9lcyBub3Qgd29yawogICAvL2dka193aW5kb3dfaW52YWxpZGF0ZV9yZWN0KHdp bmRvdy0+d2luZG93LCBOVUxMLCBUUlVFKTsKCiAgIHJldHVybiBGQUxTRTsKfQoKc3RhdGljIHZv aWQgY2xvc2UoR3RrV2lkZ2V0ICp3aWRnZXQsCiAgICAgICAgICAgICAgICAgIGdwb2ludGVyICAg ZGF0YSApCnsKICAgIGd0a19tYWluX3F1aXQgKCk7Cn0KCnN0YXRpYyB2b2lkIGNsaWNrZWQoR3Rr V2lkZ2V0ICp3aWRnZXQsCgkJICAgIGdwb2ludGVyICAgZGF0YSApCnsKICAgc3dpdGNoX21vbml0 b3JzKEdVSU5UX1RPX1BPSU5URVIodG9wb2xvZ3krKykpOwp9CgoKaW50IG1haW4oaW50IGFyZ2Ms IGNoYXIqKiBhcmd2KQp7CiAgIGd0a19pbml0KCZhcmdjLCAmYXJndik7CgogICBHdGtXaWRnZXQq IGJveDsKCiAgIHRvcG9sb2d5ID0gMDsKCiAgIHdpbmRvdyA9IGd0a193aW5kb3dfbmV3KEdUS19X SU5ET1dfVE9QTEVWRUwpOwoKICAgZ19zaWduYWxfY29ubmVjdChHX09CSkVDVCh3aW5kb3cpLCAi ZGVsZXRlX2V2ZW50IiwKCQkgICAgR19DQUxMQkFDSyhjbG9zZSksIE5VTEwpOwoKICAgZ19zaWdu YWxfY29ubmVjdChHX09CSkVDVCAod2luZG93KSwgImRlc3Ryb3kiLAoJCSAgICBHX0NBTExCQUNL IChjbG9zZSksIE5VTEwpOwoKICAgZ3RrX2NvbnRhaW5lcl9zZXRfYm9yZGVyX3dpZHRoIChHVEtf Q09OVEFJTkVSICh3aW5kb3cpLCAxMCk7CgogICBidXR0b24gPSBndGtfYnV0dG9uX25ld193aXRo X2xhYmVsICgiUHVzaCBNZSB0byBjaGFuZ2UgdG9wb2xvZ2llcyEiKTsKICAgZ3RrX3dpZGdldF9z aG93KGJ1dHRvbik7CgogICBnX3NpZ25hbF9jb25uZWN0KEdfT0JKRUNUIChidXR0b24pLCAiY2xp Y2tlZCIsCgkJICAgIEdfQ0FMTEJBQ0sgKGNsaWNrZWQpLCBOVUxMKTsKCiAgIGxhYmVsID0gZ3Rr X2xhYmVsX25ldygiSSdsbCB0ZWxsIHlvdSB3aGF0IHRvcG9sb2d5IHlvdSdyZSBpbiBoZXJlLiIp OwogICBndGtfd2lkZ2V0X3Nob3cobGFiZWwpOwoKICAgYm94ID0gZ3RrX3Zib3hfbmV3KEZBTFNF LCAxMCk7CiAgIGd0a193aWRnZXRfc2hvdyhib3gpOwoKICAgZ3RrX2NvbnRhaW5lcl9hZGQoR1RL X0NPTlRBSU5FUih3aW5kb3cpLCBib3gpOwoKICAgZ3RrX2JveF9wYWNrX3N0YXJ0KEdUS19CT1go Ym94KSwgYnV0dG9uLCBUUlVFLCBUUlVFLCAwKTsKICAgZ3RrX2JveF9wYWNrX3N0YXJ0KEdUS19C T1goYm94KSwgbGFiZWwsIFRSVUUsIFRSVUUsIDApOwoKICAgZ3RrX3dpZGdldF9zZXRfdG9vbHRp cF90ZXh0KEdUS19XSURHRVQobGFiZWwpLCAiVGhpcyBpcyBhIHRvb2x0aXAhIik7CgogICBndGtf d2lkZ2V0X3Nob3cod2luZG93KTsKCiAgIGd0a19tYWluKCk7CgogICByZXR1cm4gMDsKfQo= --0016361e86c05ad957046ad5baf0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz --0016361e86c05ad957046ad5baf0--