Review Request: Fix KWindowSystem::compositingChanged signal

[Thomas Lübking]

> On Jan. 5, 2013, 3:13 p.m., Fredrik Höglund wrote:
> > Because the XFixesSelectSelectionInput() call specifies that the event should be delivered to winId(). KSelectionOwner does not send XFixes events; they are generated by the X server.
> >
> 
> Thomas Lübking wrote:
>     Ok, problem is: whether by compiz, e17, kwin, xcompmgr - the event occurs on the root but not on winId() - even for the simplistic testcase (which also works on QApplication but for the selectionwatcher)
>     
>     I tried adding some junk into XFixesSelectSelectionInput and get a request error (as expected)
>     
>     X Error: BadWindow (invalid Window parameter) 3
>       Extension:    138 (Uknown extension)
>       Minor opcode: 2 (Unknown request)
>       Resource id:  0x3039
>     
>     yet KWindowSystem fires on compositing toggle.
>     
>     Then i removed XFixesSelectSelectionInput - and still (patched to check against root) KWindowSystem fires on compositing toggle.
>     
>     
>     
>     Now it gets interesting (I removed the KSelectionWatcher bits for the last tests):
>     -----------------------------------------------------------------------------------------
>     If i keep XFixesSelectSelectionInput AND the check against the root window i get after the event on root TWO additional events on the winId()
>     If i remove either, i get none of them (but still one on the root which however is ignored)
>     
>     So ulitmately i just ate away (return true) selectionnotify events on the root window and in return got ONE additional event on the winId which then fired the signal - what is all less then ideal, since (just as the present patch btw.) we also eat away "regular" selectionowner events.
> 
> Fredrik Höglund wrote:
>     This happens because Qt compresses XFixesSelectionNotifyEvents by deleting all events in the queue that refer to same selection except the last one. It does this without taking the destination window or the subtype into account, so it will randomly swallow either its own event or the event selected by KWindowSystem. The event you see delivered to the root window is the event selected by Qt for QX11Info::isCompositingManagerRunning().
>
> 
> Thomas Lübking wrote:
>     Ok, i can see the bug in qt_xfixes_scanner.
>     
>     -> Question is, whether we should - given the Qt4 lifecycle - just work around that for KDE4 by either relying on the Qt selection and just scanning for the root or not relying on the Qt selection and pass on root events while swallow winId() ones but hook on both to re-evaluate the compositing state.
>     
>     Is there any remote chance there'll be another Qt4 minor release?

> Is there any remote chance there'll be another Qt4 minor release?
Ok, at least there's quite some action on the git tree and the term 4.8.5 ;-)


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107983/#review24751
-----------------------------------------------------------


On Jan. 5, 2013, 5:08 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/107983/
> -----------------------------------------------------------
> 
> (Updated Jan. 5, 2013, 5:08 p.m.)
> 
> 
> Review request for kdelibs, kwin, Plasma, Aaron J. Seigo, Marco Martin, Martin Gräßlin, and Fredrik Höglund.
> 
> 
> Description
> -------
> 
> It works fine here (tested so far KWindowSystem signal, KSelectionWatcher only with kwin) with kwin (shift+alt+f12), xcompmgr, compiz & "metacity -c" and e17.
> Didn't try xfce nor mutter.
> 
> Technically:
> I do not at all understand why KWindowSystem is *not* watching the root window - KSelectionOwner for one is sending events to the root and this also seems the case for all other WMs (at least everything now starts to cause the signal to be emitted)
> 
> The KSelectionWatcher failure seems to be kwin specific (wrote me a cleaner testcase), there'll be some X11 event processing on top that eats away the client messages.
> So this one can be scratched from the patch, the KWindowSystem issue remains.
> 
> 
> This addresses bug 179042.
>     http://bugs.kde.org/show_bug.cgi?id=179042
> 
> 
> Diffs
> -----
> 
>   kdeui/windowmanagement/kwindowsystem_x11.cpp f9b3cc1 
> 
> Diff: http://git.reviewboard.kde.org/r/107983/diff/
> 
> 
> Testing
> -------
> 
> see summary
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130105/566bc33c/attachment.html>