Red Hat Bugzilla – Bug 506984
KWin won't give windows with GDK_WINDOW_TYPE_HINT_DOCK the focus, so openoffice.org presentations on dual-head KDE fails
Last modified: 2009-08-31 19:32:39 EDT
Description of problem:
when multiple monitors are set up, openoffice.org impress won't show slideshow properly.
it creates a window over one of the screens (whichever it is set to in slide show settings) that cannot be moved or closed (except with xkill), which has 2 scrollbars, but isn't updated (so it keeps whatever was drawn underneath). scrolling moves the garbage around, but no slides are shown.
escape, clicking etc doesn't work, only xkill (ctrl+alt+esc) which kills openoffice.
when displaying on a different screen, the main gui can still be interacted with, but slideshow still broken as above.
slideshow displays correctly when only one monitor is set up
it does this even with a clean blank presentation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. open openoffice.org impress
2. create empty slide show
3. slide show -> slide show (F5)
window which doesn't get updated and can't be closed, with scrollbars, but no slide show
slideshow should be displayed
Presumably this is the presenter-screen, if you tweak slideshow->slide show settings->multiple monitors to say "all monitors" that might workaround.
What's supposed to happen is you get a presenter-screen with a small preview of the slideshow on it in one of the heads that gives a view of the next slide and the speaker notes. This definitely "works for me" on an ix86 laptop with internal lcd and external panel. From what you're reporting the presenter screen isn't showing anything at all ?
setting it to all monitors doesn't change anything, it displays that non-updated fullscreen window on primary screen only and i have to xkill it.
it doesn't show anything, just what was already on the screen (the main OO gui, any other windows) along with those two scrollbars at the far left and far bottom of the screen. its simply not drawing the contents of the window
the other screen is always entirely unaffected.
bit more sys info:
was using nvidia-settings to set up second monitor to "twinview" mode.
(nvidia driver from rpm-fusion):
but I don't think this is relevent as the person who reported the same problem to launchpad (see above), has an ATI with open source driver.
i would provide a screenshot, but it would just be a boring desktop with some scrollbars.
any more info/tests you want, just ask
Maybe its not the presenter screen at all then. A screenshot would be good, anything at all that gives potentially useful information. Resolutions of screens etc.
Created attachment 348737 [details]
screenshot after starting slide show and using both scrollbars a little
here's a screenshot,
i've literally enabled the second screen, started the slideshow, and then used both scrollbars a little to show how it isn't redrawing the scroll area (notice repeated bits at edges).
i hope it helps
dtardon->james: I cannot reproduce the problem. Could you give us some more info? What desktop (or window manager) do you use? Do you have openoffice.org-presenter-screen installed? Could you attach outputs from xdpyinfo and xrandr (both should be run in terminal)? Does the problem go away when you start Impress as
from terminal? Does switching to fullscreen work for other openoffice.org applications, like Writer (menu View->Full Screen)?
I'm using KDE (4.2.3) and kwin window manager.
presenter screen is installed:
openoffice.org-presenter-screen x86_64 1:3.1.0-11.3.fc11
in fact if i try and remove it it also tries to remove impress (is that right?)
the problem does go away when using SAL_USE_VCLPLUGIN=gen
the problem does not go away when using SAL_NOOPENGL=true
fullscreen in writer works fine (without any of the above env variables)
I will attach output of xrandr and xdpyinfo in a moment.
Thanks for the assistance. let me know if there is anything else I can do.
Created attachment 348876 [details]
output of xdpyinfo
Created attachment 348877 [details]
output of xrandr
Okay, reproducible in KDE. Let's see what I can do with it...
Interesting... After switching to another workspace and back the presentation window normally reacts on events (it's not redrawn, though) and then after pressing Right (and Left to return to the first slide) everything is all right.
*** Bug 508860 has been marked as a duplicate of this bug. ***
In answer to the question posed on my (now-duplicate) bug: yes, I use KDE. I also just noticed that, if I attempt to quit OO.o while the messed-up slide show is going on (i.e., File-Quit), I get something on my screen that looks like it might be the presenter screen.
Install KDE and so forth I can see this on x86 as well.
dtardon->caolanm: The presentation window (sd::ShowWindow) is only created after its toplevel (fullscreen) window has got focus (the code doing the creation is sd::SlideshowImpl::startShow() in sd/source/ui/slideshow/slideshowimpl.cxx). Calling mpFullScreenViewShellBase->GetWindow()->GrabFocus() in sd::SlideShow::StartFullscreenPresentation() (sd/source/core/ui/slideshow/slideshow.cxx) should take care of that, but there comes the difference between Gnome and KDE: in Gnome, two focus events are sent back to oo.o: focus-out-event for taking focus out of the main app window and focus-in-event for setting it to the fullscreen window (GtkSalFrame::signalFocus() in vcl/unx/gtk/window/gtkframe.cxx). In KDE, only the first event is sent. I haven't found out why yet.... If you have any ideas to that, you're welcome.
I seem to see that if I comment out
m_nStyle |= SAL_FRAME_STYLE_PARTIAL_FULLSCREEN;
then things "work" in KDE for multi-head, that work for you as well ?
Created attachment 350254 [details]
So, doesn't seem to be the presenter-screen, just would happen with the gtk plugin under kwin when there are more than one Xinerama/Xrandr monitor.
might try and make a simple standalone demo program
Created attachment 350265 [details]
So, like dtardon says, we're not able to force focus into the presentation window, the reasons seems to be KWin's handling of windows with GDK_WINDOW_TYPE_HINT_DOCK where we never get focus for such a window.
Under metacity we do, under KWin we don't. When there is only one monitor (or when XRandr/Xinerama has two monitors configured for the same range of virtual screen) we use a different way to launch the presentation full-screen so it doesn't get triggered
dtardon->caolanm: Looks like Thorsten already changed the GDK_WINDOW_TYPE_HINT_DOCK to GDK_WINDOW_TYPE_HINT_UTILITY to solve another problem. Maybe we better use his patch?
See comment #17 for a standalone example, and compare against metacity. On KDE it will report "fail", while on metacity it will report "pass".
In the meantime I'll hack around it in our packages and if there is another update for F-11 it will be in >= 3.1.0-11.5
caolanm->dtardon: clearly similar, but still remains uncertain if its intentional for KDE to behave like this for _NET_WM_WINDOW_TYPE_DOCK windows
openoffice.org-3.1.0-11.5.fc11 has been submitted as an update for Fedora 11.
openoffice.org-3.1.0-11.5.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update openoffice.org'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-7604
Thank you for taking the time to report this issue.
This is an issue that needs to be addressed by the upstream developers. Please report this at http://bugs.kde.org and then add the upstream report information to this report. We will monitor the upstream report for a resolution to this issue, and will review any bug fixes that become available for consideration in future updates.
Setting status to NEEDINFO, and awaiting upstream bug report URL for tracking.
Thanks in advance.
Steven M. Parrish - KDE Triage Master
- PackageKit Triager
Fedora Bugzappers volunteer triage team
I've talked to the kwin developers on IRC and they dispute that it is a bug in kwin:
23:13 < amalon> Hi, i while ago i reported this bug to redhat
(https://bugzilla.redhat.com/show_bug.cgi?id=506984) which is in kwin, they asked me to report to bugs.kde.org but i can't confirm until next week that the bug is still present in kwin 4.3, can anybody tell me whether this is likely to have been fixed since 4.2 so I can report it now
23:15 < mgraesslin_> amalon: from the title it sounds like an OOo bug
23:16 < amalon> thats what I thought, but after digging it only happens on kde and they came to that conclusion
23:20 < mgraesslin_> amalon: if OOo gives window type DOCK to a window which isn't a dock it's totally unrelated how kwin handles focus for DOCKs
23:21 < amalon> mgraesslin_: tbh I don't understand exactly what they're suggesting the problem is
23:22 < mgraesslin_> amalon: as far as I have read (and understood - I'm actually quite tired) they complain that kwin doesn't give focus to dock windows
23:22 < mgraesslin_> a dock window is a panel
23:22 < amalon> right
23:23 < mgraesslin_> there is no reason why OOo gives window type dock to any of their windows
23:23 < mgraesslin_> that just aren't docks
23:23 < mgraesslin_> looks to me they worked around a bug in one window manager
23:23 < mgraesslin_> and we don't fix broken apps in the window manager ;-)
23:23 < amalon> thats making more sense to me now
23:25 < amalon> mgraesslin_: would it be possible for you to make a comment (no hurry if you're tired) on the redhat bug to that effect, as you sound more qualified than myself to make the point
23:25 < mgraesslin_> I don't have a bug tracker account and as I am currently on a developer sprint it might happen that I forget it
23:25 < amalon> ok fair enough
23:26 < mgraesslin_> you can just mention that kwin devs are confused that OOo uses docks
23:34 < amalon> I feel like I should still report the bug at kde then let discussion as to why where the fault lies happen there
23:35 < mgraesslin_> there is no fault in KDE
23:35 < mgraesslin_> at least I would not know of the spec saying that a panel should get focus
23:35 < mgraesslin_> so it's a design decision which isn't a bug
I'll await further advice as to what I should do.
Sounds like intentional behavior... now what?
openoffice.org-3.1.1-19.1.fc11 has been submitted as an update for Fedora 11.
This is hacked around in the above updates for the moment.
"there is no reason why OOo gives window type dock to any of their windows that just aren't docks" is just trite and ignores the realities of the difficulty of getting a non-trivial application to function correctly under the large amount of window managers all of which are broken in some way or other
Added to bugs.kde.org
Why can't the original WM bug OO.o was triggering just be fixed in the offending WM? AFAICT, KWin just behaves according to the spec.
The spec says nothing about focus and dock hints one way or the other. KWin is unique in its behaviour here. Either way it doesn't matter, the issue is resolved
openoffice.org-3.1.1-19.1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.