I’m running openSUSE Leap 15.2 in virtual machine and got problem with setting monitor resolution
When I am trying to change it to any, for example to 1600x1200, after few seconds it change back to default resolution, using grub settings
When I set resolution more than 1152x864 in grub settings, it just sets to 800x600 after reboot
Welcome to the openSUSE Forums!
To be able to help you we need more information, such as:
- what virtualization technology are you using (e.g. VirtualBox, KVM, other…) and in what version?
- what is the host Operating System?
- what desktop environment (KDE, Gnome, other…) are you using in the guest Leap 15.2 system?
- are you referring just to the GRUB resolution at boot or the resolution that can be set in the desktop environment?
Moved to Virtualization. because that is where the virtualization gurus lure.
App: VMware Workstaion Pro 16.x
Host: Windows 10 64-bit
Desktop envorinment: KDE Plasma
I tried set both boot and desktop environment
Please insure that your 15.2 guest is fully up to date and that xf86-video-vmware is installed.
If in doubt, please post the result of:
zypper se -i xf86-video
between CODE] tags (use the # button above the editing area).
My VMware Tools is installed already automatically
That’s output (contains russian)
С | Имя | Заключение | Тип--+-------------------+--------------------------------------------------------+------
i | xf86-video-fbdev | Видеодрайвер Framebuffer для X-сервера Xorg | пакет
i | xf86-video-vesa | Видеодрайвер общего назначения VESA для X-сервера Xorg | пакет
i | xf86-video-vmware | Видеодрайвер VMware SVGA для X-сервера Xorg | пакет
Leap 15.2 had a similar problem under VirtualBox, but an update fixed that a few weeks ago.
I don’t use VMware here, so I cannot test but maybe this page can point you in the right direction.
Or you may wait for a VMware user to chime in…
First,
Generally speaking
You should know that every Linux machine (physical and virtual, no diff) boots using a different video driver than what may be loaded once your credentials are logged in (automatically or manually) and your Desktop loads (optionally) and the “Advanced video driver” is loaded.
So, let’s take the boot time loading first, before the Advanced video driver is loaded.
That’s defined by Grub, and usually is the VESA driver by default nowadays.
But, that’s only the default because there is also a way to load the Advanced video driver early… But unless you’ve found how to set that up, I’ll assume you’re using the VESA video driver (prove me wrong if you’ve done this!)
Note that when you change this setting by either specifying a different video driver or forcing a non-default resolution, you have to re-compile your initrd (typically a mkinitrd command is required) else your setting won’t last longer that your current User session (Configuration will go back to defaults on reboot).
The above skims what happens during your system boot in text mode.
The next is what happens when your system starts loading graphical mode which is ordinarily when the Advanced video driver is also loaded…
Your login credentials are entered which also means that parts specific **only **to your User account starts loading.
Your Desktop Environment (like KDE) loads applying your User account settings.
In this graphical environment, the Advanced Video driver (in a VMware setting, the VMware video driver) loads and applies its configuration settings replacing the VESA driver and its settings.
From the above,
Hopefully the first thing that you should realize is that the system boot environment is very different than the graphical environment when you use your mouse to click on Desktop objects, they also have different configuration settings… So, when you describe whatever video settings you’re doing it’ll likely apply to one or the other but not both… Except for the fact you’re running in a virtual environment!
When you’re running in a virtual environment, you have an **additional **encompassing setting outside normal machine operation, which is the graphical console. In VMware(similar settings in other virtualization), you also have “Fit Window” and “Fit Guest” settings which tell the graphical console to either expand/shrink to fit the Console window or vice versa (expand/shrink the window to fit the existing machine display setting).
Hopefully with the above info
You can figure out what you need to do,
Else,
You need to post a better description with details what settings you’re changing and what you’re trying to accomplish(again, be sure to specify either the system boot or logged in User environment).
TSU
Here’s an example of my personal VMware Workstation configuration SOP…
I don’t care what the resolution is during boot, I only care what the resolution is once I’m logged in.
So, I just set the resolution in the Desktop.
This means that when the Guest first boots up, it’ll be at whatever the default resolution is, but once the Desktop loads, the display should be at the new, preferred resolution.
So, if I were running KDE, this would be a setting within KDE.
I typically use some other DE,
In LXQt, I’d use the LXQt tool to set the resolution to whatever I want.
If I’m running in a WM only (not a DE) like IceWM, Fluxbox, Openbox, Awesome, FvWM2, etc (there are many others), since I don’t prefer to remember how to configure xrandr I install arandr.
As long as the graphical console is then set to “Fit to Guest” you should see the same resolution every time you boot.
Note the idea is to set your resolution in your system and make the console fit, not the other way around.
TSU
If he is using wayland - there is no way.
If he is using x he can use cvt and rrandr to set any resolution that the hardware supports.
?
Explanation?
Wayland doesn’t support which setting?
Remember, the hardware is virtualized, and nowadays CPU extensions allow direct configuration of “real” hardware while GPU is not exposed the same way (of course unless a pass-through) so is always the virtualized driver.
TSU
The neat way that X uses cvt and xrandr are not supported - they are for X.
They do nothing for wayland - completely different way to do a display. Run the commands in wayland and nothing happens as they are for the X server.
I had to used cvt and xrandr to set displays to the size I want in VirtualBox because the VMSVGA - my code:
llrainey@VM1:~> cat bin/fixvideo
D=`xrandr --verbose | head -2 | tail -1 | awk '{print $1}'`
/usr/bin/xrandr --newmode "1752x980_60.00" 141.75 1752 1856 2040 2328 980 983 993 1017 -hsync +vsync
/usr/bin/xrandr --addmode $D 1752x980_60.00
/usr/bin/xrandr -s 1752x980
Thx!
Something for me to look into sometime!
TSU
The following applies to all Wayland, not just in virtual machines.
This is a bit OT for this thread because the @OP asked about running IceWM which means Wayland isn’t relevant.
Prodded by Larry’s post,
I just did a quick search on Wayland and setting the display resolution.
Yes, indeed for many years now people have observed that xrandr does not work (returns an error).
Seems that the best current info is that the setting is best configured in the Compositor you’re running.
On most Wayland systems, Weston is your installed Compositor,
Look for weston.ini, find the display resolution stanza and configure as you wish.
The setting should then be available for you when you use your Desktop tool to set your display configuration.
After seeing the above,
I took a quick look around to see if other Compositors can configure display resolutions the same way,
I took a look at Kwin as the next most likely installed Compositor (Likely to be the default nowadays on KDE/Plasma installs).
With Kwin, I had less success searching documentation…
As might be expected, editing configuration files in KDE is discouraged or less documented.
All I can say is that the User should just try configuring using standard KDE Desktop tools and see if it works. There are a lot of variables that might not be easily controlled like whether you’re really on pure Wayland or actually connected to XWayland (in which case not only would almost all display configurations likely work, you can probably also run xrandr).
The older solution described in numerous articles floating around the Internet is to try to fool the system by specifying a custom resolution as a GRUB boot option, if you’re successful, then the display resolution might be successful.
Now, reminder on a workaround that applies only to virtualization Guests…
I did run into some articles that say just stretch your screen to whatever you want.
I’d add that works only once the VMware advanced video driver is loaded and not during system boot’s VESA driver.
If you’re installed on VMware 15 or later and IIRC openSUSE 15.1 or later, this will work when running only a WM like IceWM, the screen won’t dynamically re-size on older openSUSE(have to run xrandr and you don’t have to worry about Wayland which isn’t relevant).
TSU