Hello Genodeans
I would like to use my virtual machine in fullscreen mode on my sculpt. If I'm interpreting the configuration of the floating_window_layouter correctly, the key combination [SCREEN]+[ENTER] will toggle the fullscreen mode of a window.
Further there is a normally disabled configuration in /config/input_fliter that remaps the key [LEFTMETA] to [SCREEN]. However when I enable the remapping and start the wm and the virtual machine, pressing [LEFTMETA] and [ENTER] as described in the sequence of the layouter.config nothing happens.
Do I need to change something else?
Best regards, Pirmin
Hi Pirmin,
On 03.07.2018 08:15, Pirmin Duss wrote:
I would like to use my virtual machine in fullscreen mode on my sculpt. If I'm interpreting the configuration of the floating_window_layouter correctly, the key combination [SCREEN]+[ENTER] will toggle the fullscreen mode of a window.
Further there is a normally disabled configuration in /config/input_fliter that remaps the key [LEFTMETA] to [SCREEN]. However when I enable the remapping and start the wm and the virtual machine, pressing [LEFTMETA] and [ENTER] as described in the sequence of the layouter.config nothing happens.
Do I need to change something else?
by default, Sculpt is configured such that all key combinations involving the 'SCREEN' key to the window layouter. In config/input_filter, 'LEFTMETA' (windows key) is mapped to 'SCREEN' by default. In contrast to your observation, it is not disabled. Do you happen to use a stale input_filter configuration?
Does [LEFTMETA]+[TAB] works for cycling through multiple windows? If yes, then the input filter and window layouter are configured correctly. This should be the case by default.
The VM's response to maximize events (as triggered by [LEFTMETA]+[ENTER] or by the maximize button at the top-left window corner) is a bit of a hit-or-miss, unfortunately. The screen-size change is handled the VBox guest additions. So it does only work when those are installed and running. Even if so, it sometimes takes quite a long time for the screen change to take effect. The delay needs further investigation. But apart from this, it should work in principle.
Cheers Norman
Hi Norman
On 05.07.2018 12:44, Norman Feske wrote:
Hi Pirmin,
On 03.07.2018 08:15, Pirmin Duss wrote:
I would like to use my virtual machine in fullscreen mode on my sculpt. If I'm interpreting the configuration of the floating_window_layouter correctly, the key combination [SCREEN]+[ENTER] will toggle the fullscreen mode of a window.
Further there is a normally disabled configuration in /config/input_fliter that remaps the key [LEFTMETA] to [SCREEN]. However when I enable the remapping and start the wm and the virtual machine, pressing [LEFTMETA] and [ENTER] as described in the sequence of the layouter.config nothing happens.
Do I need to change something else?
by default, Sculpt is configured such that all key combinations involving the 'SCREEN' key to the window layouter. In config/input_filter, 'LEFTMETA' (windows key) is mapped to 'SCREEN' by default. In contrast to your observation, it is not disabled. Do you happen to use a stale input_filter configuration?
Yes, now I remember. I disabled this as otherwise the LEFTMEAT key wasn't working inside the VM.
Does [LEFTMETA]+[TAB] works for cycling through multiple windows? If yes, then the input filter and window layouter are configured correctly. This should be the case by default.
This works, the color of the title bar changes slightly.
The VM's response to maximize events (as triggered by [LEFTMETA]+[ENTER] or by the maximize button at the top-left window corner) is a bit of a hit-or-miss, unfortunately. The screen-size change is handled the VBox guest additions. So it does only work when those are installed and running. Even if so, it sometimes takes quite a long time for the screen change to take effect. The delay needs further investigation. But apart from this, it should work in principle.
Now letting the VM "rest" after pressing maximize for a long time the machine switched to full screen mode. So switching fullscreen works (as usual I was not patient enough with the computer ;-) ).
Would it be faster to set the size of the nit_fb from outside (kind of like it is done when the window is resized)?
Best regards, Pirmin
Hi Pirmin,
On 05.07.2018 13:30, Pirmin Duss wrote:
Yes, now I remember. I disabled this as otherwise the LEFTMEAT key wasn't working inside the VM.
you should definitely map [LEFTMEAT] to [BBQ]. ;-)
Would it be faster to set the size of the nit_fb from outside (kind of like it is done when the window is resized)?
No. The resize mechanism of the window manager is quick. You can see it when resizing a terminal window. I suspect the problem lies in our console backend of VirtualBox. I remember that the resizing was much smoother in VirtualBox 4. With version 5, this console infrastructure changed completely.
Just speculating, we may miss to inject a virtual interrupt once the screen mode changes. So the guest additions detect the change eventually (e.g., when getting an interrupt for another event) but not immediately. But that is just a guess.
Cheers Norman
Just an idea I head before...
On Thu, Jul 05, 2018 at 02:15:09PM +0200, Norman Feske wrote:
Would it be faster to set the size of the nit_fb from outside (kind of like it is done when the window is resized)?
No. The resize mechanism of the window manager is quick.
[...]
It may be worthwhile to add code to the VirtualBox console that centers virtual framebuffers in the used Framebuffer session on a black background. This would look nicer in the boot phase and would also instantly act on window size change (before the guest is able to adapt).
Greets
Hi everyone
I want to get a better understanding related to the resizing (in general, not only full screen) of virtual box guest screens.
On 07/05/2018 07:41 PM, Christian Helmuth wrote:
It may be worthwhile to add code to the VirtualBox console that centers virtual framebuffers in the used Framebuffer session on a black background. This would look nicer in the boot phase and would also instantly act on window size change (before the guest is able to adapt).
I agree. At [1] is a *very* basic/raw/incomplete implementation. For now I just ignore some obvious problems:
- The pointer event coordinates are off exactly the x/y-offsets used to center the virtual framebuffer inside the used Framebuffer session.
- During the boot phase of the guest (Debian 9.4) it seems to happen that the wrong screen regions are redrawn.
- The login screen is screwed up...
What puzzles me more right now is the following behavior: when I grab and drag the resize handle of the window decorator in order to change the size of the window, the window edge doesn't "follow" the mouse pointer. Only after a delay of about 2 seconds of no mouse motion, the window border reflects the new dimensions. For me it looks like the window layouter "waits" until the guest additions acknowledges the resize hint?
Some other questions related to development/debugging in this "area":
- Editing files in ports/src/virtualbox5 results in a long build time - is there a way to circumvent that?
- I'd like to add diagnostic debug messages to the VirtualBox console to get an idea when which method is called - but this makes only sense if a can simultaneously see the virtual box window and the log terminal. I changed the alpha attribute of nit_fader in /config/leitzentrale from 0 to 100. But then I cannot grab the window resize handle any more to trigger the log output...
Any hints are are welcome.
Thanks, Roman
[1] https://github.com/rite/genode/commit/56cb0625cf52693bbf1205b412d5de41dbae4f...
Hi,
On 19.07.2018 22:02, Roman Iten wrote:
What puzzles me more right now is the following behavior: when I grab and drag the resize handle of the window decorator in order to change the size of the window, the window edge doesn't "follow" the mouse pointer. Only after a delay of about 2 seconds of no mouse motion, the window border reflects the new dimensions. For me it looks like the window layouter "waits" until the guest additions acknowledges the resize hint?
In general, the new sized window will be become active as soon as the client requests the framebuffer dataspace.
For Vbox5 it takes place in NotifyChange of repos/ports/src/virtualbox5/frontend/fb.h. This method is called by the VBox5 contrib sources as acknowledgement of the accepted change in size (whatever this means and whenever this happens).
If you earlier request the framebuffer dataspace, you will get an immediate visible window resize effect. However you must then take some care, e.g. Vbox may still work with he old (outdated) size parameters, and you have to handle it (e.g. not to overwrite memory or page faulting due to too small framebuffers ...).
Some other questions related to development/debugging in this "area":
- Editing files in ports/src/virtualbox5 results in a long build time -
is there a way to circumvent that?
Yeahno, maybe. The headers in this folders are kind of central, as they are directly used by the Vbox5 sources. You may of course try to remove the implementation of functions out of the headers and put in own compilation units, so that a implementation change does not trigger a whole rebuild. Additionally, you may of course try to split up the large and big virtualbox5-main library in smaller pieces, in order that not everything gets rebuild.
- I'd like to add diagnostic debug messages to the VirtualBox console to
get an idea when which method is called - but this makes only sense if a can simultaneously see the virtual box window and the log terminal. I changed the alpha attribute of nit_fader in /config/leitzentrale from 0 to 100. But then I cannot grab the window resize handle any more to trigger the log output...
What about starting just the noux pkg from the /config/deploy next to the Virtualbox pkg and make there a "tail -f report/log".
Cheers,
Alex.
Hello,
On 07/20/2018 09:36 AM, Alexander Boettcher wrote:
If you earlier request the framebuffer dataspace, you will get an immediate visible window resize effect.
In [1] the framebuffer dataspace is requested in Genodefb::update_mode, which is called noticeable earlier than NotifyChange. The diagnostic warning log entry reflects the desired width and height with just a tiny delay to the mouse movement. But still, the window border only updates after the mouse pointer didn't move for around 2 seconds.
At least at first glance the patch doesn't change anything at all - it doesn't event introduce the anticipated page faults, ...?
- I'd like to add diagnostic debug messages to the VirtualBox console to
get an idea when which method is called - but this makes only sense if a can simultaneously see the virtual box window and the log terminal.
What about starting just the noux pkg from the /config/deploy next to the Virtualbox pkg and make there a "tail -f report/log".
Ehrm, yes - that would be easy enough ;)
Cheers, Roman
[1] https://github.com/rite/genode/commit/64b517533d36f9a6506025e942bd33ddf4e095...
On 25.07.2018 12:39, Roman Iten wrote:
Hello,
On 07/20/2018 09:36 AM, Alexander Boettcher wrote:
If you earlier request the framebuffer dataspace, you will get an immediate visible window resize effect.
In [1] the framebuffer dataspace is requested in Genodefb::update_mode, which is called noticeable earlier than NotifyChange. The diagnostic warning log entry reflects the desired width and height with just a tiny delay to the mouse movement. But still, the window border only updates after the mouse pointer didn't move for around 2 seconds.
I guess maybe a fb.refresh(0,0,maxx,maxy) is missing ? (or use _clear_screen() which does it also.)
[1] https://github.com/rite/genode/commit/64b517533d36f9a6506025e942bd33ddf4e095...
-
Alexander Boettcher -
Christian Helmuth -
Norman Feske -
Pirmin Duss -
Roman Iten