Window extending beyond limits of monitor

I’ve got a real issue and haven’t found a correction. I’ve been reading a lot to try to find how to fix this, and don’t have a lot of time for more reading - and haven’t found an answer.

I have three monitors. The central monitor is the main one, and my largest (I think 21 inches) - resolution is 1920x1080. The monitor setup screen names it #3. To the left is my next biggest monitor (HP2009m) (#2), and that is usually where the problem shows up. The resolution is 1600x900, and it’s a tiny bit shorter than my main monitor. To my right is the smallest, and the resolution is 1280x1024 (labeled Monitor #1). I use all three almost all the time.

Problem: often the leftmost monitor - programs will open there and there is no way to ‘reach’ the top bar - it’s essentially beyond the limits of the monitor itself. I cannot move the window (this time Remmina) back to the main monitor (central one). I don’t want to close it because I’ve been doing work on it. I’d been trying to resize the window and for some reason that forced it to monitor “2” and put the top bar of that window ‘beyond reach’.

Is there some way to limit the program windows to the maximum physical extents of the monitors? Basically make sure that the top bar is always accessible? (Clicking on the program on the bottom bar - I can only maximize or minimize or close the window - no moving.)

I’ve looked at dconf editor, settings, and Tweaks, but didn’t see anything that could help with the problem.

Thanks for any help!
Bob

Hi
In the settings -> Displays you can define monitor position, size etc and also set which monitor is considered ‘Primary’ and retain the ‘Top’ bar.

I would check the output from xrandr;


xrandr --listactivemonitors
xrandr --listmonitors

Then compare with Settings -Displays as to which monitor is what…

Last but not least, all screen settings are stored in ~/.config/monitors.xml once you have an acceptable setup, I always make a backup and can always copy back and use alt+F2 r <enter> to restart the Gnome-Shell.

In general, it’s least troublesome for the largest resolution display to be the primary display. Depending on what connections are used for the displays, it may be best to move the cable/connection that currently serves up as the #1 output to the largest display. If that’s not possible, xrandr in a startup script can override the display considered primary to any of the others. Assuming your #3 1920x1080 display has an xrandr connection named HDMI-2, the command would be ‘xrandr --output HDMI-2 --primary’. As to where to put such script, I create a file with it in /etc/X11/xinit/xinitrd.d/. When not using a configuration utility provided by your DE, if using a DE, arandr is available to assist in positioning and xrandr script creation.

When encountering a problem with top of window unreachable, a keyboard hotkey should be available to enable moving the window, depending on the DE or WM in use. A hotkey can also maximize a window, which should normally maximize to the dimensions of the display in which the window is primarily placed.

malcolmlewis, what about post #1 spells OP is using Gnome?

Hi
The use of dconf-editor and Tweaks :wink: Pressing the super key will activate overview.

In Plasma (oS 15.1) you can hold down LEFT-ALT and drag the window with the mouse. It’s enough that the mouse pointer is anywhere in the window. I don’t know about Gnome, however…

Thanks for the replies! I apologize for not mentioning clearly that I was using Gnome - been under too much stress for too long and I often forget to mention things (sometimes important ones).

I also had the same issue with Ubuntu 20.04, but there was a selection for moving when you right-clicked the program (on the bottom bar). I looked in the hotkey list to see if there was a ‘move window’ combination, but didn’t see one.

I’ll look into creating a hotkey combination for move (not sure how to do it - more reading needed). I’ve got the system setup (with the exception of this problem) pretty much how I want it - and thanks for the tip on saving the layout. The highest resolution monitor is the main one (0 on the list generated by xrandr, #3 in setup), the second highest #2, and the third highest shows up as #1 (this one connected via VGA cable). I’ve played with rearranging the monitors and their connections - it didn’t really make a difference, although I think I now have the main one in (I guess you could say) position one (or “0”) on the computer. Moving the monitors around in the monitor settings screen also made no difference.

I don’t know if this matters or not, but the computer is a Dell, quad core 3.4Ghz, 16mb ram, and the video is via the motherboard (works best for 3 monitors in my experience). The GFX is Intel Xeon E3-1200 v2/3rd gen core @ 4800x1080.

Thanks again!

I did a few experiments with an apparent IGP match to OPs. This first is the result of not using xrandr, IOW, no special configuration. VGA is leftmost & primary, DP center, and HDMI to the right, with KDE’s toolbar on the VGA “primary”:

# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
VGA-1 connected **primary** 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384
HDMI-3 connected 2560x1080+4480+0 (normal left inverted right x axis y axis) 673mm x 284mm
DP-1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   2560x1080     60.00*+
   1920x1200     59.95*+
# inxi -GSay
System:
  Host: ab85m Kernel: 5.3.18-lp152.63-default x86_64 bits: 64 compiler: gcc v: 7.5.0
  ...
  Desktop: KDE 3 info: kicker wm: kwin vt: 3 dm: startx
  Distro: openSUSE Leap 15.2
Graphics:
  Device-1: Intel **Xeon E3-1200** v3/4th Gen Core Processor Integrated Graphics
  vendor: ASUSTeK driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0402
  class-ID: 0300
  Display: server: **X.Org 1.20.3 driver: loaded: modesetting**
  unloaded: fbdev,vesa alternate: intel display-ID: :0 screens: 1
  Screen-1: 0 s-res: 7040x1440 s-dpi: 120 s-size: 1490x304mm (58.7x12.0")
  s-diag: 1521mm (59.9")
  Monitor-1: VGA-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  Monitor-2: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
  diag: 686mm (27")
  Monitor-3: HDMI-3 res: 2560x1080 hz: 60 dpi: 97 size: 673x284mm (26.5x11.2")
  diag: 730mm (28.8")
  OpenGL: renderer: Mesa DRI Intel **Haswell** Desktop v: 4.5 Mesa 19.3.4
  compat-v: 3.0 direct render: Yes

This one differs mainly in using xrandr to set the DP’s display as primary, which moved the toolbar from VGA to DP:

# xrandr --dpi 120 --output DP-1 --primary
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
VGA-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384
HDMI-3 connected 2560x1080+4480+0 (normal left inverted right x axis y axis) 673mm x 284mm
DP-1 connected **primary** 2560x1440+1920+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   2560x1080     60.00*+
   1920x1200     59.95*+
# inxi -GSay
System:
  Host: ab85m Kernel: 5.3.18-lp152.63-default x86_64 bits: 64 compiler: gcc v: 7.5.0
  ...
  Desktop: KDE 3 info: kicker wm: kwin vt: 3 dm: startx
  Distro: openSUSE Leap 15.2
Graphics:
  Device-1: Intel **Xeon E3-1200** v3/4th Gen Core Processor Integrated Graphics
  vendor: ASUSTeK driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0402
  class-ID: 0300
  Display: server: **X.Org 1.20.3 driver: loaded: modesetting**
  unloaded: fbdev,vesa alternate: intel display-ID: :0 screens: 1
  Screen-1: 0 s-res: 7040x1440 s-dpi: 120 s-size: 1490x304mm (58.7x12.0")
  s-diag: 1521mm (59.9")
  Monitor-1: VGA-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  Monitor-2: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
  diag: 686mm (27")
  Monitor-3: HDMI-3 res: 2560x1080 hz: 60 dpi: 97 size: 673x284mm (26.5x11.2")
  diag: 730mm (28.8")
  OpenGL: renderer: Mesa DRI Intel **Haswell** Desktop v: 4.5 Mesa 19.3.4
  compat-v: 3.0 direct render: Yes

This one switches from using VGA to using DVI, another without using xrandr. DP apparently became primary, but leftmost, with DVI in center and HDMI still rightmost. Inexplicably, xrandr skipped reporting which output was primary, but the toolbar fell to the DP:

# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384
HDMI-3 connected 2560x1080+4480+0 (normal left inverted right x axis y axis) 673mm x 284mm
HDMI-2 connected 1920x1200+2560+0 (normal left inverted right x axis y axis) 519mm x 324mm # **DVI**
DP-1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   2560x1080     60.00*+
   1920x1200     59.95*+
# inxi -GSay
System:
  Host: ab85m Kernel: 5.3.18-lp152.63-default x86_64 bits: 64 compiler: gcc v: 7.5.0
  ...
  Desktop: KDE 3 info: kicker wm: kwin vt: 3 dm: startx
  Distro: openSUSE Leap 15.2
Graphics:
  Device-1: Intel **Xeon E3-1200** v3/4th Gen Core Processor Integrated Graphics
  vendor: ASUSTeK driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0402
  class-ID: 0300
  Display: server: **X.Org 1.20.3 driver: loaded: modesetting**
  unloaded: fbdev,vesa alternate: intel display-ID: :0 screens: 1
  Screen-1: 0 s-res: 7040x1440 s-dpi: 96 s-size: 1862x381mm (73.3x15.0")
  s-diag: 1901mm (74.8")
  Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
  diag: 686mm (27")
  Monitor-2: HDMI-2 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") # **DVI**
  diag: 612mm (24.1")
  Monitor-3: HDMI-3 res: 2560x1080 hz: 60 dpi: 97 size: 673x284mm (26.5x11.2")
  diag: 730mm (28.8")
  OpenGL: renderer: Mesa DRI Intel **Haswell** Desktop v: 4.5 Mesa 19.3.4
  compat-v: 3.0 direct render: Yes

This again uses DVI instead of VGA, but uses xrandr to move the DP back to center, HDMI to the left, while DVI stays rightmost:

# xrandr --output DP-1 --primary --output HDMI-3 --left-of DP-1
# xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384
HDMI-3 connected 2560x1080+0+0 (normal left inverted right x axis y axis) 673mm x 284mm
HDMI-2 connected 1920x1200+5120+0 (normal left inverted right x axis y axis) 519mm x 324mm # **DVI**
DP-1 connected **primary** 2560x1440+2560+0 (normal left inverted right x axis y axis) 598mm x 336mm
   2560x1440     59.95*+  74.92
   2560x1080     60.00*+
   1920x1200     59.95*+
# inxi -GSay
System:
  Host: ab85m Kernel: 5.3.18-lp152.63-default x86_64 bits: 64 compiler: gcc v: 7.5.0
  ..
  Desktop: KDE 3 info: kicker wm: kwin vt: 3 dm: startx
  Distro: openSUSE Leap 15.2
Graphics:
  Device-1: Intel **Xeon E3-1200** v3/4th Gen Core Processor Integrated Graphics
  vendor: ASUSTeK driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:0402
  class-ID: 0300
  Display: server: **X.Org 1.20.3 driver: loaded: modesetting**
  unloaded: fbdev,vesa alternate: intel display-ID: :0 screens: 1
  Screen-1: 0 s-res: 7040x1440 s-dpi: 120 s-size: 1490x304mm (58.7x12.0")
  s-diag: 1521mm (59.9")
  Monitor-1: DP-1 res: 2560x1440 hz: 60 dpi: 109 size: 598x336mm (23.5x13.2")
  diag: 686mm (27")
  Monitor-2: HDMI-2 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") # **DVI**
  diag: 612mm (24.1")
  Monitor-3: HDMI-3 res: 2560x1080 hz: 60 dpi: 97 size: 673x284mm (26.5x11.2")
  diag: 730mm (28.8")
  OpenGL: renderer: Mesa DRI Intel **Haswell** Desktop v: 4.5 Mesa 19.3.4
  compat-v: 3.0 direct render: Yes

Hi
I had a similar setup (Xeon E3, Intel GFX), except all three of my monitors are the same (1920x1080), same with the xrandr output I saw the same on the old setup as well as on this new setup (Xeon E5, AMD RX550) running Tumbleweed and GNOME 40. to me I think it’s a bug. I’m guessing your on Xorg rather than Wayland?

I believe so. I haven’t gotten that far into the workings yet… just did the install and added software that I use often (still have several packages to go). I also have wondered if it was some sort of bug, but while I do know a little, I’m not sure about this issue. It ‘feels’ buggy to me - that’s based on being around computers since the early 70s, but I couldn’t explain why. I could be wrong.

It’s the default installation setup for Gnome Classic as far as I know. (I’m a little more used to working with Xorg, from all the years I used Ubuntu and Xorg was more or less a default.)

Thanks, everyone for ideas and suggestions!!!

If I could add a suggestion to the programmers - please add “Move” to the list of “titlebar buttons” that pops up when you (secondary) click on the program in the bottom bar (on the main monitor) - and/or a hotkey for moving a window (when you cannot access the top bar for the program).

Hi
Have a look in settings -> keyboard for the hot key setup to move windows, I think you will find what you are after there :wink:

When you get a chance, can you create a test user, then try classic, Xorg and Wayland to see if the issue duplicates?

OK, will do - finding time is difficult, but I will try the different users testing. It’s worth looking into, but I have found out some significant things about the problem…

In the meantime (since my last post), I DID find the keypress combination for moving a window, but the one that was stuck (Remote Desktop) - it wouldn’t work. Part of the problem with the “Move Window” combination is clearly connected to Remmina… once (after fighting with it for hours), I got it into a window instead of the fullscreen setting, I could move it without an issue and the key combination (Alt - F7) started working on it. However, I still have other windows that have opened in the left monitor with the top-bar missing.

So it seems to me that this is a combination of two problems - one caused by Remmina, the other (more generic) having to do with a second screen that is smaller than the primary - and happens when programs open up in the second monitor.

I’m back in operation now, but I think (once I get some very priority projects done) I will explore this more later. What I think was happening was that Remmina was capturing all keyboard presses occurring within the main remote window, and sending them to my remote computer - not allowing combinations that could have caused problems with my work system. Thus I had great difficulty resizing the window.

Thanks, everyone, for jumping in on this issue. I’ll probably be popping up with new ones very shortly… one problem at a time right now!

I do still think that as part of the click combinations for the bottom bar, “Move” should be added. It could have freed up a lot of time spent trying to figure this one out! (No blame, but I think a good suggestion for a minor change…)