Version: unspecified (using KDE 4.5.0) OS: Linux Since I upgraded to KDE 4.5.0 (former 4.4.4) maximized windows stretch across both screens in my dual-screen setup. especially annoying is the fact that windows that were previously maximized on the single screen are stretched when the second screen is activated. there is no easy way to resize them to their former size. Reproducible: Always Steps to Reproduce: 1. activate second screen 2. maximize unmaximize windows Actual Results: maximizing windows stretches them across both monitors Expected Results: maximized windows take all available space on their current screen (as it was until 4.5.0)
Checking: window on left screen maximzed? yes ;-) Of course multi screen is still supported and I would immediately notice it. Nevertheless I beleave you that it is not working for you, but I think that it is a configuration issue. Unfortunately you omitted to name same important information like which graphics card/driver, if you use xrandr/twinview/whatever. My first thought was some distro problem, but this looks unlikely in case of Gentoo :-)
I used xrandr to activate the second screen after pluging it in: xrandr --output VGA1 --auto --right-of LVDS1 after issuing that command and waiting until everything settled down. the desktop behaved as if there was one single (virtual) monitor that enclosed both screens. the controlbar which I had previously at the right border of LVDS1 was suddenly at the right border of VGA1. Also LVDS1 is a bit smaller (height-wise) than VGA1 so the desktop (maximized windows, controlbars) reached beneath the border of LVDS1. so it seems that KDE didn't know that there were two screens. thanks for reminding me to put more information into this bug report ;) currently I'm downgrading to 4.4.5 as I need dual screen support for my production environment. but if you still can't reproduce this, I'm willing to setup an extra installation with 4.5 or even the current git version.
I'm on Gentoo as well and was facing exactly the same thing after upgrading from KDE 4.4.5 to 4.5.0. Here, adding the global 'xinerama' USE flag solved this issue.
Hi Timo, I recompiled kde now with the global xinerama USE-flag enabled. But it didn't change the behavior a bit. This time I also tried to use the krandrtray for changing the settings - but it didn't make any difference. Here is the output from xrandr (This time the external monitor is above my laptop's display): Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 VGA1 connected (normal left inverted right x axis y axis) 1280x1024 60.0 + 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm 1366x768 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) >>> xrandr --output VGA1 --auto --above LVDS1 Screen 0: minimum 320 x 200, current 1366 x 1792, maximum 8192 x 8192 VGA1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.0*+ 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 LVDS1 connected 1366x768+0+1024 (normal left inverted right x axis y axis) 256mm x 144mm 1366x768 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) >>> xrandr --output VGA1 --off Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 VGA1 connected (normal left inverted right x axis y axis) 1280x1024 60.0 + 75.0 1280x960 60.0 1152x864 75.0 1024x768 75.1 70.1 60.0 832x624 74.6 800x600 72.2 75.0 60.3 56.2 640x480 72.8 75.0 66.7 60.0 720x400 70.1 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm 1366x768 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) And the xsession-error.log during this time (filtered out some messages from kio_imap): file retriever error: 114 file retriever error: 114 display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! kwin(8502) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8502) KWin::Workspace::updateClientArea: Done. file retriever error: 114 file retriever error: 114 plasma-desktop(8530)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: plasma-desktop(8530)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: plasma-desktop(8530)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: plasma-desktop(8530)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: QWidget::setMinimumSize: (/Plasma::Dialog) Negative sizes (-1,-1) are not possible file retriever error: 114 file retriever error: 114 display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! kwin(8502) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8502) KWin::Workspace::updateClientArea: Done. display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! kwin(8502) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8502) KWin::Workspace::updateClientArea: Done. display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! display-randr(8998) RandROutput::handleEvent: FIXME: Output event ignored! kwin(8502) KWin::Workspace::updateClientArea: screens: 1 desktops: 4 kwin(8502) KWin::Workspace::updateClientArea: Done. file retriever error: 114 file retriever error: 114 Is the any more information that I can provide you with? What would be the next steps if I wanted to debug this myself?
I have the same problem here. intel driver 2.9.1 xorg-server-1.7.7 didn't have xinerama for the last 2 years, not needed anymore.
is anyone seeing this issue and *not* using Gentoo?
Doesn't look like it. I attached the configure log of my kwin. Maybe you can take a look and tell me what's wrong? Or where would the code that handles the multi-head support be?
Created attachment 50882 [details] kwin configure and make
enabling xinerama on build time did the trick for me as well, never needed this before now. This also leads to a new tab in the display settings. the funny thing is that initially maximize on both screens worked but everything was very slughish and I had a lot of artifacts. furthermore having separate taskbars for the two screens did not work. So I displayed the multi monitor support in display settings kde, used xrandr to set them both up again and voila I have my old behaviour back. no artifacts, maximize works and I have my split taskbar. Next funny thing is that the display settings dialog shows multi monitors enabled again, lets see what the next start brings...
Just to be sure xinerama is not actually activated in my xorg.conf at all. the extension is not loaded. So the question is why kde needs the xinerama configure flag?
I just want to confirm Michaels' comments. It seems that the dependency on the xinerama configure option is somehow screwed up. Neither I have Xinerama activated in xorg.conf nor was required in KDE < 4.5 for my purpose. PS. I wasn't facing the artifacts and sluggishness, though.
well I still have some. it's definitely not as smooth as with 4.4.5 without xinerama.
Hmm, it's perfectly snappy here at two different computers. (intel i965 and ATI r770 [OSS driver])
alright, its not as it should be. with 4.4.5 and no xinerama I had a second panel on the second screen with a taskbar. This would only be there if I had the second screen. when I'm abroad with my laptop and only one screen I would not have that one. Now with 4.5 I switched to one screen (basically started laptop at home) and the second panel was moved to my laptopscreen instead of not being there. So xinerama has some unwanted effects.
let's face it: it's not a kwin issue. I don't know if something changed with the gentoo xinerama useflag but at least in kwin nothing changed and even if it would be "packaging related", so a downstream issue. The other mentioned problems (slugginess compared to 4.4 or panels on each screen) have also nothing to do with this bug report.
For me the xinerama useflag DOES NOT SOLVE THE PROBLEM. So it isn't fixed for me - neither up, nor downstream.
I reported a ticket downstream, fact is that dual monitor should work without xinerama if xrandr is available. it did for 4.4.5
(In reply to comment #16) > For me the xinerama useflag DOES NOT SOLVE THE PROBLEM. So it isn't fixed for > me - neither up, nor downstream. Sorry, this isn't a bug in KWin. As this report illustrates it has been at least for some users a configuration problem by their distribution. There is nobody except Gentoo users experiencing this problem. Keeping this bug open won't fix it for you, because we as KWin developers cannot do anything about it as our code is working correctly if compiled with the correct switches.
Martin could you take a Look at the attachment i Attached and point out what is wrong in your opinion. Thanks mike
"Disabling Xinerama as requested on commandline." Btw if someone now thinks that we have to get rid of xinerama/only use xrandr: that's not possible. We still need xinerama for NVIDIA as they only support xinerama. So it's something like ~1/3 of our user base.
I understand but as said before for many if us 4.4.5 worked great without xinerama. Actually better! Has something changed? I've intel myself and shouldn't need xinerama should I?
Almost the same here. I also have an Intel card … * It worked fine with 4.4.x with and without (!) xinerama * It doesn't work in 4.4.5 with and without xinerama So if we take it to that level we have two issues: 1. For some users it worked fine without xinerama in 4.4 and it doesn't work in 4.5 - without there being a rational explanation. 2. For me (aka original reporter) it doesn't work either way in 4.5. Both issues - while only observed by gentoo users - are not necessarily caused by gentoo's packaging. So again: No this bug isn't fixed. And no it is not necessarily downstream. The downstream bug-report is found at http://bugs.gentoo.org/show_bug.cgi?id=334669 BTW.
This bug here is resolved because there is nothing we can do about it. It has to be fixed in a different component. We did not change anything - I'm sorry about it that you have problems but we are innocent ;-) That's what downstream means: not a bug in this component but in a different layer. As only Gentoo users are seeing that problem it has to be a gentoo problem. Please think about it: we have millions of users with multi screens and if this would break we would have more complaints. If something like this breaks we have other KDE developers reporting immediately. This bug report is the first time that I hear about Multi Screen not working correctly. Btw. the first user to notice it would be me :-) I completely understand that you want this issue to be fixed, but as said: our code is working fine if build correctly. I do not know enough about Gentoo to help you there. But this renders this report here as incorrect. Please also note that this is a bugtracker for existing problems in the source code and not a user support forum. Fixing build issues in Gentoo is support and does not belong here. I can only suggest to have a look at kephal. I think there were changes in 4.5 and it might be that you have to rebuild it with xinerama flag or whatever as well. Btw. this bug report illustrates nicely why the Gentoo way of building does not work: users cannot know what is required and what not. I don't nee Xinerama because I have XRandR can result in errors.
> As only Gentoo users are seeing that problem it has to be a gentoo problem. That's definitely a false conclusion: Imagine a software which is broken when installed in a different location than /usr. All distros except one do this. And for the only one which installs it ie. in /opt you would blame the distro, right? I installed all of KDE with the xinerama enabled and it didn't help for me - so it's not a question of which packages to rebuild with this flag either. From this I conclude: If I report a bug that only users of my own distro report (note: there is no reason to believe that nobody else _has_ that problem). It's going to be rejected except when I have bullet-proof evidence the cause lies not in the package to blame? Fine - you won't get a lot of bug reports from me in the future. If you suspect it's in kephal, then why don't you reassign this bug? Do I have to open one bug-report for each kde-component which might be involved in a bug, in the future? BTW: Two of the reporters (including me) also asked about where to find the code that decides multiple screens vs. one big screen to debug it themselves. Even if you believe that this bug does not belong to kde does it really hurt that badly to keep it open until it's resolved (upstream, downstream, sidestream or whatever …)? I see no sense in closing all bugs that _might_ not be valid. So I can start the 6h compilation to upgrade kde again, just to provide you with a build log that says "building with xinerama" and it still won't work for me (I have tried that). Not all bugs affect all systems, closing them because "most systems" work is still wrong.
> > As only Gentoo users are seeing that problem it has to be a gentoo > > problem. > > That's definitely a false conclusion: Imagine a software which is broken > when installed in a different location than /usr. All distros except one > do this. And for the only one which installs it ie. in /opt you would > blame the distro, right? *sigh* what do you want to achieve with such comparisons? I am able to judge each bug report independently. In this case, yes I am totally sure that it is *not* a KWin problem. I have several indicatiors for that and one of them is the fact that only Gentoo users are affected. > > I installed all of KDE with the xinerama enabled and it didn't help for me > - so it's not a question of which packages to rebuild with this flag > either. As I said, I do not know enough about Gentoo to help you setting all required useflags. And that should *not* be discussed in this bugtracker. That is user support your distribution has to provide. > > From this I conclude: If I report a bug that only users of my own distro > report (note: there is no reason to believe that nobody else _has_ that > problem). It's going to be rejected except when I have bullet-proof > evidence the cause lies not in the package to blame? Fine - you won't get > a lot of bug reports from me in the future. The conclusion is wrong. > > If you suspect it's in kephal, then why don't you reassign this bug? Do I > have to open one bug-report for each kde-component which might be involved > in a bug, in the future? I do not suspect that it is in kephal. It was just a hint which other components you have to compile *correctly*. If you have compiled kephal with the wrong useflags it's as invalid here as there. And I do not move bugs around just because I think it might be related. > > BTW: Two of the reporters (including me) also asked about where to find the > code that decides multiple screens vs. one big screen to debug it > themselves. Sorry missed that one, but it's as easey as doing a grep for xinerama on kwin source code. Most of the xinerama related code is in geometry.cpp > > Even if you believe that this bug does not belong to kde does it really > hurt that badly to keep it open until it's resolved (upstream, downstream, > sidestream or whatever …)? RESOLVED DOWNSTREAM does not mean that it is already fixed in the downstream component, it means that we cannot do anything about it as it has to be fixed in another layer. This is the correct flag for such bugs. Keeping it open does not make any sense at all, because we cannot do anything about it. This is a bugtracker for bugs in our software, not for bugs in other software. > > I see no sense in closing all bugs that _might_ not be valid. Feel free to start triaging kwin bugs. You will soon notice how much it does not make sense to keep them open. > > So I can start the 6h compilation to upgrade kde again, just to provide you > with a build log that says "building with xinerama" Please don't provide a new build log as I won't read it. Remember: this is an issue tracker, not a support forum. I do not know how to compile KWin in Gentoo so that it works. > and it still won't work > for me (I have tried that). Not all bugs affect all systems, closing them > because "most systems" work is still wrong. In this case: yes it is. And yes we do that as a general pattern at least for driver bugs. If we cannot do anything about a bug, because it is triggered by an upstream or downstream component, we cannot do anything about the bug. Please remember: KDE only distributes source code. Integration with other components and building correct packages is done by distributions. And please do not continue the discussion whether the bug should be kept open or not. It won't help resolving your problem.
Agreed this is not a discussionboard, one last item though. We do not want to use xinerama, but xrandr. Apart from kephal where would we find code related to our dual screen issue?
> Agreed this is not a discussionboard, one last item though. We do not > want to use xinerama, but xrandr. Apart from kephal where would we find > code related to our dual screen issue? You don't need to *use* xinerama, you nee to *build* with xinerama support enabled. It's a compile time thing, not a runtime. To be sure that everything works I would suggest to build complete kdebase with xinerama support and I would further suggest to have a look on what parts are disabled in the build. While kwin has hardly any hard requirements a missing optional requirement removes quite some functionality - as seen in this report. My kdebase build includes everything except google gadgets. Btw it is possible that even after recompiling with all the correct flags an option in the config file still says that multi screen is not supported. So you might have a look in systemsettings and verify that everything is set correctly: Multiple monitors -> option "Enable multiple monitor window maximize support".
Martin, I moved this now to a forum http://forum.kde.org/viewtopic.php?f=111&t=89957 I think we have a misunderstanding. In 4.4.5 everything worked as I wanted it too. I just checked in 4.4.5 kwin was compiled with xinerama turned off as well. the multi monitor section in the display system module was disabled all the time, but still maximize would work fine among other things that no longer work. Please be so kind and read the forum post and try to answer as good as possible.
Same problem here but on Kubuntu 10.04 (with KDE 4.5 from ppa:backports) I have nvidia and use their nvidia-settings to set up twinview. KDE (Display Settings) sees this as a single display with a resolution that is the accumulation of the two (one is 1440x900 the other 1280x1024 and KDE sees a single display with a 2720x1024 resolution), at least width-wise
As discussed on the forum, it seems to be a problem with KDE noticing the screen configuration change, in my example, enabling twinview. Saving the twinview configuration to xorg.conf and restarting the server, makes 'multiple monitors' module to work properly and the desktop behaves as expected. So it looks like some events are lost or not generated in the first place. Can other people with non-nvidia hardware test if this is the case in their platforms as well?
There Must Be more. As Said i use Intel with multi and sometimes singlescreen. Kde used to remember all my panels positions now it will always place them on the primary screen on startup
We now have several different distributions and at least two different types of hardware that have problems with dual screen. Can we reopen this bug? 1. intel hardware used to work fine without xinerama now it needs it 2. nvidia twin screen does not work properly when it is not done via xorg.conf 3. Switching between mutli and single screen is inconvenient as KDE does not remember where the panels used to be I still have this behaviour with 4.5.1 and I actually have another case: 1. Switch to dual screen with KDE display (2 external, internal turned off) 2. restart your notebook into single screen (no external) 3. open KDE display settings 4. It will turn off the internal one and "turn on" the non existing external ones. This got me trying to change it back blindly via xrandr and konsole a couple of times
I don't see the originally described behavior on a newly installed system. My next guess would be, that hald is not running on systems having this error.