Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

window height of the VirtualBox guest screen size #26

Open
marco-237 opened this issue Feb 6, 2023 · 11 comments
Open

window height of the VirtualBox guest screen size #26

marco-237 opened this issue Feb 6, 2023 · 11 comments

Comments

@marco-237
Copy link

In WM the screen size (height) of the guest window of VB keeps returning to a few pixels, which is really annoying.
Is there a way of forcing the screen size in VB to a specific size?

It seems to be a bug in WM since other window managers don't show this behaviour.

Regards,
Marco
@marco-237 marco-237 changed the title window height of the guest screen size in VirtualBox window height of the guest screen size of VirtualBox Feb 7, 2023
@marco-237 marco-237 changed the title window height of the guest screen size of VirtualBox window height of the VirtualBox guest screen size Feb 7, 2023
@dmaciejak
Copy link
Contributor

I had that issue long time ago but did not seeing it recently.
Which windowmaker version and virtualbox version are you using ?
What are the steps to reproduce the issue ?

@marco-237
Copy link
Author

WindowMaker version is 0.95.9. VirtualBox version is 6.1.36.
It happens every time the login screen of the client is shown. Then it flips to 640x3 (instead of 640x480). After logging in it flips to 1680x3 (instead of what I want 1680x1050). Every time I have to resize the screen to the size I want, because the height is too small to see anything. And everytime it flips back to the height of a few dpi. This behaviour is seen only in WindowMaker, not in other wm's. When logged in in the guest OS, and after a resize it stays that way, But after an automatic screen lock, it flips back to 640x3.

@dmaciejak
Copy link
Contributor

I had that issue in the past when I was not installing the VirtualBox Guest Additions (the virtualbox-guest packages).
But as you mentioned other WMs are working fine it may be a different issue on your side. I am currently using virtualbox 7.0.6 but I can try to replicate it on my side if you could also share with us what OS (linux?), distro and version you are using.

thanks,
david

@marco-237
Copy link
Author

OS is FreeBSD 13.1-STABLE

@dmaciejak
Copy link
Contributor

Cannot reproduce the issue on my side.
Here the tests I did:
*I installed a fresh FreeBSD 13.1-STABLE on my virtualbox v7.0.6
*I installed the windowmaker maintainer release
*use .xinitrc to launch wmaker
*from there I tried to move/iconify/maximise/resize the virtualbox window, working well
*save and restore the virtualbox machine state, working well
*tests with and without the virtualbox-ose-additions package on the guest
*tests around changing x11 conf to use the vboxvideo or vesa
*tests with virtualbox settings video memory decreased
*tests with virtualbox settings different graphic controllers

One thing to mention, seems that the windowmaker maintainer release is not compiled with randr support.

@marco-237
Copy link
Author

In my case FreeBSD is the host OS and Kali Linux is the guest, but doesn't matter which guest OS I run. Only difference with here is that VB v7 isn't in FreeBSD yet so maybe that's the solution. I'll check the randr issue.

@marco-237
Copy link
Author

marco-237 commented Feb 12, 2023 •
edited
Loading

Hmm I've just rebuilt WindowMaker with randr support but no diff.
I'll try to update the VB port to the latest 6 version (6.1.42).

@marco-237
Copy link
Author

With a newer VB (6.1.42) version it's better, but not ideal. The height flips now to 480 instead of 3.
xprop shows:
_NET_WM_ICON_NAME(UTF8_STRING) =
XdndAware(ATOM) = BITMAP
WM_NAME(STRING) = "Kali1 [Running] - Oracle VM VirtualBox"
_NET_WM_NAME(UTF8_STRING) = "Kali1 [Running] - Oracle VM VirtualBox"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x1200008
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
window id # of group leader: 0x1200008
WM_CLIENT_MACHINE(STRING) = "yokozuna"
_NET_WM_PID(CARDINAL) = 1748
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 18874382
WM_CLASS(STRING) = "VirtualBox Machine", "VirtualBox Machine"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 1, 750
user specified size: 1680 by -35
program specified minimum size: 329 by 106
window gravity: Static

The "user specified size" shows negative height, which should be 1050. So there's still something broken.

@dmaciejak
Copy link
Contributor

dmaciejak commented Feb 16, 2023 •
edited
Loading

Good news I was able to reproduce the issue with VirtualBox version is 6.1.36.
Bad news the issue is coming from VirtualBox itself.
Seems a few tickets were opened on the VirtualBox side already like https://www.virtualbox.org/ticket/15863

When debugging WindowMaker, we can see that VirtualBox is requesting to create the guest window with a wrong height size in my case (843x65508).
When checking the property of that window with xprop, we can see:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified location: 1, 563
                user specified size: 843 by -28
                program specified minimum size: 292 by 110
                window gravity: Static

The user specified size is so big that it's overflowing the max value as defined in X11, that's why it's displayed as a negative value.

On the WindowMaker side, an attempt some time ago was made to mitigate that issue and that's why you are getting a height of 480 pixels, that's basically the failsafe implemented for such case.
See https://repo.or.cz/wmaker-crm.git?a=commit;h=6668715402a5d8e2ecda6702076a06bf8988721e
I will most probably provide a better patch in the coming days to cover more corner cases, but nothing much can be done.

@marco-237
Copy link
Author

Yeah this is what I'm seeing too. Thanks for the effort!
But where is the extreme "user specified size" coming from?

@dmaciejak
Copy link
Contributor

From VirtualBox itself when it's creating the guest window, it's sending to the wm the size request ..

crmafra pushed a commit to crmafra/wmaker that referenced this issue Feb 22, 2023
@dmaciejak @crmafra
Detect and override illegal window size hints v2
62405fb 
The patch is trying to mitigate and properly address the issue described at
window-maker/wmaker#26
A buggy application (in that example virtualbox) is requesting a window size creation
that is way too big and basically at the limit of X11 protocol
(width and height are defined as CARD16).
See details at https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html
During the tests, virtualbox has been seen requesting for window creation of size 843x65508.
Even xprop is reporting incorrect values.

There had been an attempt before with the commit
https://repo.or.cz/wmaker-crm.git?a=commit;h=6668715402a5d8e2ecda6702076a06bf8988721e

But the patch is broken and not implemented at the right place.
As described in the wWindowConfigure function header, the size passed by the client app
should not be trusted and should be vetted with a prior call to wWindowConstrainSize.
wWindowConstrainSize call was missing only once in the wClientConfigure function from client.c
What wWindowConstrainSize doing now is basically setting a failsafe window size fo 640x480
if both width and height are above the size of CARD16.
If only one dimension is oversized, it's setting a default 4/3 window ratio.
Oversized here has not been changed and it's defined in windowmaker as double the screen size.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dmaciejak @marco-237