Bug 711479 - gnome shell problem when multi monitor and external one is above
Summary: gnome shell problem when multi monitor and external one is above
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 20
Hardware: All
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 751668 875819 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-06-07 15:23 UTC by Gianluca Cecchi
Modified: 2014-04-24 13:22 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-24 13:22:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
contents of Xorg.0.log while trying to set up external monitor above laptop one (35.86 KB, text/plain)
2011-06-07 15:24 UTC, Gianluca Cecchi
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 663690 0 None None None 2019-01-21 15:34:43 UTC

Description Gianluca Cecchi 2011-06-07 15:23:02 UTC
Description of problem:
I have a Dell laptop XPS M1330 with
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8400M GS] (rev a1)
When using gnome-shell and connecting vga external monitor I cannot use it in a configuration where it stays above the laptop display.
Instead it is ok if I put external monitor below the laptop display.
In fallback mode the behaviour is ok.

Version-Release number of selected component (if applicable):
xorg-x11-drv-nouveau-0.0.16-24.20110324git8378443.fc15.x86_64

How reproducible:
always

Steps to Reproduce:
1. set native gnome-shell mode
2. configure external monitor (vga connected) above the laptop one 
3. manage windows
  
Actual results:
I cannot put a window inside the external monitor.
If I drag it stops right under the top bar (the activities, calendar, ecc.. one)

Expected results:
To be able to use external monitor with a configuration that mimics the physical layout, so laptop display below and external monitor above.

Additional info:

no xorg.conf configured
I'm going to attach Xorg.0.log when trying configuration with external monitor above and below

Comment 1 Gianluca Cecchi 2011-06-07 15:24:08 UTC
Created attachment 503515 [details]
contents of Xorg.0.log while trying to set up external monitor above laptop one

Comment 2 Ben Skeggs 2011-06-07 22:46:49 UTC
Hah, odd bug.  I can confirm this behaviour.  Not likely to be the video driver's problem however, reassigning.

Comment 3 Gianluca Cecchi 2011-06-08 06:58:55 UTC
Hi,
it seems the top bar of gnome shell is "impenetrable wall (from below)" (copyright Adam Jackson ;-).
In fact if I go in systems settings --> displays 
- set external display on top
- drag and drop the top bar (yes I can drag it too...) from the top of laptop to the top of external monitor (so at the absolute top of display layout) 

Then I can use correctly the configuration.

the problem is that if at a certain time I have to disconnect the external monitor, I completely loose the top bar: in fact it is not "automagically" repositioned as it would desirable. And I cannot work without manual intervention.

Tested in both fallback ad gnome-shell mode: it fails for both configurations.

In both configurations if I re-connect the external display I regain the remembered config and keep on working.

Another working test that could be represent real situation: 

- environment with gnome-shell
- external monitor on top and top bar on top of it
- working normally
- shutdown the system (go home simulation ;-)
- disconnect vga 
- startup the system (you have to work @home too, where you don't have the external monitor.. ;-)
- gnome shell starts correctly with the top bar on top of laptop display.

HIH,
Gianluca

Comment 4 Gianluca Cecchi 2011-06-08 06:58:55 UTC
Hi,
it seems the top bar of gnome shell is "impenetrable wall (from below)" (copyright Adam Jackson ;-).
In fact if I go in systems settings --> displays 
- set external display on top
- drag and drop the top bar (yes I can drag it too...) from the top of laptop to the top of external monitor (so at the absolute top of display layout) 

Then I can use correctly the configuration.

the problem is that if at a certain time I have to disconnect the external monitor, I completely loose the top bar: in fact it is not "automagically" repositioned as it would desirable. And I cannot work without manual intervention.

Tested in both fallback ad gnome-shell mode: it fails for both configurations.

In both configurations if I re-connect the external display I regain the remembered config and keep on working.

Another working test that could be represent real situation: 

- environment with gnome-shell
- external monitor on top and top bar on top of it
- working normally
- shutdown the system (go home simulation ;-)
- disconnect vga 
- startup the system (you have to work @home too, where you don't have the external monitor.. ;-)
- gnome shell starts correctly with the top bar on top of laptop display.

HIH,
Gianluca

Comment 5 Gianluca Cecchi 2011-06-08 07:40:50 UTC
BTW: the windows that are placed in the lower display (laptop one) appear in every workspace, not only in the one where I first opened them.
Instead the upper display respects windows appearance.

It think this is not expected behaviour, is it?

I had this same incorrect behaviour of lower display windows also with nvidia proprietary driver and configuration set up with this in xorg.conf:
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    DefaultDepth    24
    Option         "TwinView" "1"
    Option "MetaModes" "CRT-0: 1280x1024 +0+0, DFP-0: 1280x800 +0+1024; CRT-0: NULL, DFP-0: 1280x800; CRT-0: 1280x1024 +0+0, DFP-0: NULL"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

It was with xorg-x11-drv-nvidia-270.41.06-1.fc15.x86_64 from rpmfusion.
I think this is a general problem of gnome-shell and independent from display driver used.

Comment 6 Samuel Sieb 2011-06-08 07:45:52 UTC
The workspace thing is the intended behavior. There is a setting somewhere to adjust that.

Comment 7 Gianluca Cecchi 2011-06-08 08:22:04 UTC
Bad default in my opinion. Is this upstream or Fedora default?

Tried running gnome-tweak-tool but I didn't find this setting...

Comment 8 Gavin Ebum 2011-06-19 13:18:49 UTC
I have this problem too.
My solve is: move the top monitor a little left/right from the notebook screen, so you can drift windows to the top one. Hope there is a patch for this bug.
To Gianluca:
Do you mean the option: workspaces_only_on_primary ?
In config-editor, 
/desktop/gnome/shell/windows/workspaces_only_on_primary

Comment 9 Samuel Sieb 2011-06-20 05:42:33 UTC
That is the setting I was referring to.  Sorry, I didn't get around to looking it up.

Comment 10 Gianluca Cecchi 2011-06-20 08:23:53 UTC
Ok, at least changing (unchecking) that setting did the workspace trick.
Thanks,
Gianluca

Comment 11 Jens Petersen 2012-03-19 07:05:05 UTC
Still happening in F16 and F17 gnome-shell.

Comment 12 Jens Petersen 2012-03-19 07:05:34 UTC
*** Bug 751668 has been marked as a duplicate of this bug. ***

Comment 13 Christopher Beland 2013-02-11 19:09:39 UTC
In Fedora 18, I am seeing the behavior where trying to drag a window from the lower monitor to the upper monitor past the black menu bar causes the window to get "stuck" on the black menu bar.  I did discover that it is not an "impenetreble wall"; if I drag the window a considerable distance above the black menu bar, it eventually does hop to the upper monitor.  I agree this is not ideal behavior.

I suspect this is related to more general dual-monitor snap problems described on Bug 832820.

Comment 14 Christopher Beland 2013-02-11 19:10:27 UTC
*** Bug 875819 has been marked as a duplicate of this bug. ***

Comment 15 Christopher Beland 2013-02-11 19:25:56 UTC
Bug 832829 is a duplicate of Bug 746462, which has been reported upstream.

Comment 16 Christopher Beland 2013-02-11 19:26:41 UTC
Sorry, the previous comment should read:

Bug 832820 is a duplicate of Bug 746462, which has been reported upstream.

Comment 17 Fedora End Of Life 2013-07-04 01:41:29 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 18 Jens Petersen 2013-07-04 09:24:16 UTC
What is the upstream bug#?

Anyway I am pretty sure this is still true for 3.6 (f18)
and probably also f19 (3.8).

Comment 19 jakub.jedelsky 2013-12-20 09:48:09 UTC
There is still the same problem in F20 with Gnome Shell 3.10.2.1-3.fc20.

Comment 20 Fedora End Of Life 2013-12-21 08:28:05 UTC
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 21 Fedora End Of Life 2014-02-05 11:48:59 UTC
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 22 Michael S. 2014-02-05 15:16:31 UTC
Reopen and set to F20 per comment #19

Comment 23 Gianluca Cecchi 2014-02-05 15:25:36 UTC
In my case with Fedora 20 I "solve" the problem setting the external monitor as "primary". This way the Activities bar is suddenly moved on top of the external monitor and I can use all the workspace sum of the two  monitors.
I don't know if it is possible to keep the activities bar in the top of the laptop monitor but let the window cross it to go on top one.
ALso, now there is no choiche to drag and drop the bar itself from laptop monitor to external one or viceversa as there was before.

Comment 24 Florian Müllner 2014-04-24 13:22:44 UTC
This issue has been fixed upstream in 3.12.1, which is already in Rawhide.


Note You need to log in before you can comment on or make changes to this bug.