[SOLVED]VMWare resize issue

faceyneck · 2018-01-05 20:13:53

Hey all, Arch Community,

This is an ongoing problem that I'd love to get some information about, and I'm hoping I can get it from here and not go to VMWare forums:

After reboot(s), sometimes the guest OS (Arch) will resize just fine. Auto resize; go full screen; switch to a different monitor; exit full screen; all of these will work great.

Other times I'll reboot and VMWare won't resize at all.

Here's some basic information. I'm going to assume that I'll leave out a few details that need to be edited in later, but to start:

                   -`                    
                  .o+`                   ------------------------
                 `ooo/                   OS: Arch Linux x86_64
                `+oooo:                  Host: VMware Virtual Platform Ne
               `+oooooo:                 Kernel: 4.14.11-1-zen
               -+oooooo+:                Uptime: 16 mins
             `/:-:++oooo+:               Packages: 1356
            `/++++/+++++++:              Shell: bash 4.4.12
           `/++++++++++++++:             Resolution: 2560x1440
          `/+++ooooooooooooo/`           DE: KDE
         ./ooosssso++osssssso+`          WM: KWin
        .oossssso-````/ossssss+`         Theme: Breeze Dark [KDE], Adwai]
       -osssssso.      :ssssssso.        Icons: Papirus [KDE], Adwaita []
      :osssssss/        osssso+++.       Terminal: konsole
     /ossssssss/        +ssssooo/-       CPU: Intel i7-4790K (6) @ 4.000z
   `/ossssso+/:-        -:/+osssso+-     GPU: VMware SVGA II Adapter
  `+sso+:-`                 `.-/+oso:    Memory: 2525MiB / 7958MiB
 `++:.                           `-/+/ 
 .`                                 `/

This issue seems to be relevant, but I've applied that fix (making the necessary .desktop file) and the problem still persists.
I've applied all 3 of these potential solutions as well

Lastly, when this bug occurs, I can still manually adjust screen resolution from within Arch guest, but my main monitor's native resolution (2560x1440) is unavailable. And if I throw it onto my secondary monitor (1366x768) the closest there is available is 1360x768. Close enough for fullscreen, but on my 2k monitor I can only go significantly too wide or too narrow.

[EDIT]Host OS is currently Windows 7. Also this unresolved post might be worth noting.
Finally, I've found out recently that if I exit fullscreen mode, resize the desktop from within the guest Arch system to something larger (I've tried up to 2560x1600, and 1920x1440, as 2560x1440 isn't available when this bug happens) and then click on the Enter fullscreen Mode button (not doing the hotkey combination of Ctrl+Alt+Enter, which is used to toggle fullscreen) the desktop will now autofit correctly.
[/EDIT]

Last edited by faceyneck (2018-01-14 20:15:21)

lo1 · 2018-01-05 20:36:18

Hi faceyneck,
I don't know if I'm just tired or you need to explain your issue and what you did with a bit more effort: you're trying to resize the window which is hosting Arch as a VMWare virtual machine, and sometimes it fails. I still don't understand what the links you posted are good to.

What about your host OS? You're not telling us about it. AFAIK drawing and resizing a window is the host's task (an exception that I know is VGA passthrough but let's forget that for now).

Last edited by lo1 (2018-01-05 20:37:53)

faceyneck · 2018-01-05 23:34:00

That's the issue; sometimes it will not resize. Other times it will. And it's something that pops up after the guest is rebooted.

Host OS is Windows. I'm sorry I didn't mention that earlier. I'll add that to my initial post.

I was hoping the link I posted would show up at the right area, namely the wiki section regarding the resizing issue, including 3 potential solutions, listed under Window resolution autofit problems. I've applied all 3 potential solutions and it works most of the time, and when it doesn't work I don't know what the cause of the failure is.

The second link I posted to is in relation to a bug, which if I understand it correctly is causing open-vm-tools to silently fail.

open-vm-tools' vmware-user-suid-wrapper binary has an undocumented dlload-based dependency upon the gtkmm library. the open-vm-tools package doesn't have a dependency upon the library's package, therefore copy/paste will never work in VMWare guest OSes and it fails silently.

Yes, drawing and resizing windows is the host's task, and I have other VMs that work just fine. It's really just my Arch guest OS that's the problem. Debian, for example, works as expected and it has yet to fail.

Hope that helps explicate the issue.

Oh and lastly, I'll add this to my first post. (I'd forgotten about it until now.)

I've found that if I exit fullscreen, then go into the guest and choose Displays and adjust the resolution up to something that's bigger than what it defaults to after a reboot (800x600), and then click on the Enter fullscreen mode it will then autofit as expected. This isn't a 100% fix, and it doesn't work every time either. It's just the only thing that's fixed it for me... sometimes.

I'd found an Arch forum post about this issue that's not closed here

Thanks for your time,

Facey

seth · 2018-01-06 09:32:24

The auto-update could be related to the plasma compositor, simply try with suspended compositor.
Not sure about the available resolutions, but the EDID data is provided by the host (do you check/set the resolutions via xrandr or the KDE gui thingy?)

Xironman · 2018-01-06 09:53:23

I found that the recent update to open-vm-tools broke autofit for me too. Instead of downgrading, I found that enabling the vmtoolsd.service fixed my problem. This goes slightly against that indicated within the wiki, as I ultimately boot into a graphical target.

Last edited by Xironman (2018-01-06 09:56:03)

faceyneck · 2018-01-11 03:13:55

Thanks for the input, guys.

I think I'm gonna just mark this as [SOLVED] if that's alright. I've been trying to get this thing to happen again to me for days now.
It had happened twice when trying to exit Discord due to what appears to be an issue with Discord/Discord-Canary's cache

In particular, I think that might be causing my system to lock up because of this message from the DiscordCanary.install file:

post_upgrade() {
    post_upgrade() {
    echo ">>> You may need to delete discord's cache directory ~/.cache/discord"
    echo ">>> try this if discord is stuck on the updating screen or if nothing displays but a gray box"
    echo ">>> If you are experiencing a (A JavaScript error occurred in the main process) error try deleting the /tmp/discordcanary.sock file"
    echo ">>> if this doesn't work ask for help in #linux-general in the Discord Testers server https://discord.gg/discord-testers"
    echo ">>> You may also want to check out the linux server for help as well https://discord.gg/e7GX27C"
}

I've had the chat window go blank, then when I try to quit the program, the whole computer freezes.

Anyway, that's why I think my system froze (kernel panic?) and after reboot, the resize issue showed up. Those may very well be completely unrelated problems, and I'd assume so; they just happened to show up around the same time so I thought I'd mention it.

I'll check the logs to see what's said about the discord-canary issue, but I'm assuming that's completely different.

I re-did what Xironman said; enabling vmtoolsd.service. And yes, I seem to remember I read that; enable vmtoolsd.service if you aren't going to be booting into a graphical target. That, in conjunction with the unusual way of resizing I described above, seems to have made the issue go away.

Arch Linux

#1 2018-01-05 20:13:53

[SOLVED]VMWare resize issue

#2 2018-01-05 20:36:18

Re: [SOLVED]VMWare resize issue

#3 2018-01-05 23:34:00

Re: [SOLVED]VMWare resize issue

#4 2018-01-06 09:32:24

Re: [SOLVED]VMWare resize issue

#5 2018-01-06 09:53:23

Re: [SOLVED]VMWare resize issue

#6 2018-01-11 03:13:55

Re: [SOLVED]VMWare resize issue

Board footer