Incorrect initial terminal size on macOS with multiple screens

[gergelyk]

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20230113-210839-14c749e

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Wzterm opens up with incorrect number of rows and cols:

This applies only to large numbers. Small sizes work correctly:

To Reproduce

Open wezterm with settings shown on the screenshots above.

Configuration

Correct configuration:

    initial_cols = 160,
    initial_rows = 24,

Incorrect configuration:

    initial_cols = 160,
    initial_rows = 36,

Expected Behavior

tput cols corresponds to initial_cols. tput lines corresponds to initial_rows.

Logs

not available

Anything else?

I observed the same for the latest nightly version: wezterm 20230113-210839-14c749e

[wez]

On macOS, the system won't let you open a window larger than the screen will allow and will resize it smaller, so my initial suspicion is something like that, depending on the size/dpi of your screen.

Please open the debug overlay (CTRL-SHIFT-L in the default key bindings, or define your own assignmennt: see ShowDebugOverlay), then type in wezterm.gui.screens() and share the output.

Then, run:

WEZTERM_LOG=wezterm_gui::termwindow=trace,wezterm_gui::termwindow::render=info,info wezterm start --always-new-process

that will log some information about the selected geometry in the first 20-30 lines; please share the output here.

[gergelyk]

Debug Overlay
wezterm version: 20221119-145034-49b9839f
OpenGL version: Apple M1 Pro 4.1 Metal - 76.3
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
> wezterm.gui.screens()
{
    "active": {
        "height": 1080,
        "max_fps": 60,
        "name": "C24F390",
        "scale": 1,
        "width": 1920,
        "x": 0,
        "y": 0,
    },
    "by_name": {
        "Built-in Retina Display": {
            "height": 2234,
            "max_fps": 120,
            "name": "Built-in Retina Display",
            "scale": 1,
            "width": 3456,
            "x": -3456,
            "y": -74,
        },
        "C24F390": {
            "height": 1080,
            "max_fps": 60,
            "name": "C24F390",
            "scale": 1,
            "width": 1920,
            "x": 0,
            "y": 0,
        },
    },
    "main": {
        "height": 1080,
        "max_fps": 60,
        "name": "C24F390",
        "scale": 1,
        "width": 1920,
        "x": 0,
        "y": 0,
    },
    "origin_x": -3456,
    "origin_y": -74,
    "virtual_height": 2234,
    "virtual_width": 5376,
}
>

[gergelyk]

wezterm.log

wezterm.lua.txt

[wez]

Can you talk me through what is happening in the log? It looks like the window is opened at 160x32 on the retina display then is resized after being created at the correct size, and then lands on 322x57 size... but at 72dpi.

Is the window getting opened and staying on the retina display? Is being moved to/from the C24F390 display? If you disconnect that external display, does that "fix" this issue?

[gergelyk]

Indeed, it seems that macOS has much to do with this issue. In the case above my setup is:

• retina display - built-in display of my macbook.

• C24F390 - external display.

• Focus is on C24F390.

• I launch wezterm.

• It pops up on C24F390 display. At least it is not noticeable if it pops up on retina display and moves quickly to C24F390.

• Size of wezterm is not as expected.

When I disconnect C24F390, the issue is gone. Size of wezterm is as expected when it opens.

[wez]

Thanks; I think the issue lies within this code:

https://github.com/wez/wezterm/blob/730c41b7e371947c0a8d883534fff7d71b3e8a9f/window/src/os/macos/window.rs#L490-L509

I think it probably needs a little bit of smarts to avoid assuming 0,0 as the coordinates to use for the cascade logic, and perhaps to compare whatever default positioning info might be set on the window at creation time and mapping that back to the set of screens to find an appropriate set of coordinates that way.

[wez]

I made a change that may help with this. It should be available in the next nightly build in about an hour from the time this comment is posted. Please try it out and let me know how you get on!

[gergelyk]

My config is still the same:

    initial_cols = 160,
    initial_rows = 36,

When I open western on the external screen:

Let me know if you need logs or more information.

[wez]

Can you try a recent nightly build? I think this has been resolved as part of:

• https://github.com/wez/wezterm/issues/3503

[gergelyk]

Unfortunatelly with wezterm 20230425-083942-6686adba the issue still persists.

[bgrasmo]

I'm also experiencing this problem, though it seems to be related to using external (to wezterm) fonts for me. The version I'm using is 20240226-174525-22424c32

I've attached my simple config where I've set initial columns/rows to 128x24, but using font MesloLGS gives me 258x48, while using FiraCode or IntelOne Mono gives me 276x50 when launching on my external display. If I don't set a font I get the expected 128x24 when launching on my external display.

Launching on the built-in display gives me the expected 128x24 for all fonts, so my workaround is to launch there and move the terminal to my external display, though I wish I didn't have to do that of course.

wezterm-simple-config.txt wezterm-screens-debug.txt wezterm-startup-trace.txt

[askegg]

I am having similar issues.

When launching on the builtin display everything works as expected.

When using the external display, new windows are massive.

However, I have mapped CTRL-0 to resize the window to the default settings, which works.

[mayorbyrne]

I suspect I am seeing the same issue. I have it set-up so that wezterm launches maximized with the following:

wezterm.on('gui-startup', function(cmd)
  local tab, pane, window = mux.spawn_window(cmd or {})
  window:gui_window():maximize()
end)

I've included debug logs for both the built-in monitor (which opens maximized, as expected) and my Dell external monitor (which opens as a small window in the upper left) in the following gist -- included is a screenshot of the terminal opening small in the external monitor

[yerke]

I was affected by this issue for a long time, and so I finally decided to investigate it further. Here are my findings so far:

When you have a setup with Retina screen (such as MBP internal screen) and non-Retina external monitor, ConnectionOps.screens (link) incorrectly calculates virtual_rect. Specifically it doesn't adjust for scaling factor, which is 2 for Retina displays and 1 for non-Retina displays. Current algorithm completely ignores scaling factors and just naively adds backing coordinates.

Here is one of the setups I have checked:

The top display is an external non-Retina monitor and the bottom one is an internal MBP Retina display. As you can see, non-Retina display (which has both frame and backing frame (width of 3440, height of 1440), and scale of 1) is bigger than the internal one (which has frame (width of 1728, height of 1117) and backing frame (width of 3456, height of 2234), and scale of 2). But virtual_rect is incorrectly calculated as having width of 3456 (max of 3440 and 3456) and height of 3674 (1440 + 2234).

Some helpful resources I used while trying to understand macOS's behavior: https://www.thinkandbuild.it/deal-with-multiple-screens-programming/ https://stackoverflow.com/questions/14579880/strange-nsscreen-coordinates https://stackoverflow.com/questions/21751105/mac-os-x-convert-between-nsview-coordinates-and-global-screen-coordinates https://developer.apple.com/documentation/appkit/nsscreen https://developer.apple.com/documentation/appkit/nsscreen/1388389-convertrecttobacking https://developer.apple.com/documentation/appkit/nsview/view_coordinates

I opened a draft PR that adds additional logs and the results from running on my machine. Hopefully it will be helpful with fixing this issue.

[kambala-decapitator]

still the case in 20251014-193657-64f2907c