This patch partially converts the Sculpt manager to the dialog API.
At this stage, both the old utilities and the new dialog API are still
used simultaneously.
Issue #5008
The so-called 'Distant_runtime' implements GUI dialogs via menu_view
components hosted at a distant init instance as opposed to child
components (as implemented by the 'Sandboxed_runtime'). This is
particular the case in Sculpt OS where the sculpt manager is not the
parent of the menu_view instances.
Issue #5008
By renaming 'Dialog' to 'Deprecated_dialog', we become able to use the
name 'Dialog' for the new API while temporarily keeping the original
interface in tact.
Issue #5008
- Increase default timeout to one minute
- Ignore power-button events during display-driver startup to avoid
entering another forced blank when pressing the power button twice.
- Prevent wakeup from user activity except for the power button.
So the volume can be adjusted without leaving the screensaver.
Issue #4950
The new API at gems/include/dialog/ aids the creation of simple GUI
applications based on the menu-view widget renderer. Its use is
illustrated by the simple test application at src/test/dialog/
that is accompanied with the dialog.run script.
Issue #5008
Each hover change of the character position within a label results in a
new hover report, which needs to be evaluated by the application. For
the common cases where labels are used as button texts or for presenting
passive information, the level of detail is not needed while the
recurring hover reports induce overhead at the application side.
This patch mitigates this overhead by excluding labels from the hover
reporting by default.
For use cases that actually depend of precise hover reporting of labels,
for example an editable text area, the hover reporting can be enabled by
setting the 'hover="yes"' attribute of the label.
The 'Widget::_version' attribute was meant to allow the deliberate
replacement of a widget by a same-named widget by changing the version
while keeping the name, thereby suppressing any geomety animation.
However, the implementation missed to populate the attribute with the
value provided by the dialog ROM, prompting the unconditional
re-creation of the widget whenever a 'version' attribute was specified.
Even though this had the (desired) effect of preventing geometry
animations, it could cause feedback loops between hover reports and
dialog ROMs because the 'hover_changed' condition in 'Menu_view::Main'
would always stay true while a versioned widget is hovered.
To prevent exessive allocations the bounce buffers are allocated
once and afterwards re-used. The DMA buffers are provided by an
range allocator whose backing store increases in 4 MiB chunks.
The range allocator might not merge the ranges as those chunks
are not necessarily allocated continously. Allocations larger
than the static chunk size are therefor treated as error.
Internally libyuv uses malloc & free for short time dynamic memory
allocation during image transformation. The converted images are
such large, that the Libc allocator will create and destroy new Genode
dataspace per image. In time sensitive code paths, the overhead can be
noticeable by the caller of the image transformation.
The patch adds the option to register callbacks in the libyuv library to
implement the image allocation by users of the library. They may implement
caching strategies to avoid the overhead, e.g. as seen with qemu-usb and
the webcam model.
and not before. On Windows guest with more than 1 vCPU, the packets
seem to arrive and/or seem to be handled too late in the Webcam model.
An intermediate state, to due the late packet, has been used to decide to
close the Capture session too early.
In SDL2, support has been added for multiple windows.
As such, prior to this commit, invoking _sdl_screen.construct
would create a new window each time the original window was
resized.
To avoid this, refactor to only construct the window once, and
upon resize events, reconstruct the SDL_Surface and SDL_Texture
of Sdl_screen to the new window dimensions.
Issue identified by @chelmuth in https://github.com/genodelabs/genode/pull/4993#issuecomment-1729530634Fixes#4993
Following the official migration guide of SDL [1], the
fb_sdl framebuffer driver was update from SDL1 to SDL2.
The sdl2 port in world/src/lib/sdl2 is used.
Since SDL1 is in maintenance mode [2], support for other
display servers than X11 will never be implemented. In
particular, support for Wayland is missing from SDL1.
Fortunately, a port of sdl2 is maintained in genode-world.
As SDL2 is actively developed, it will provide support for
modern hardware architectures, and has mature support for
Wayland [3].
[1]: https://wiki.libsdl.org/SDL2/MigrationGuide
[2]: https://wiki.debian.org/Wayland#SDL1_.28unsupported.29
[3]: https://wiki.debian.org/Wayland#SDL2_.28supported_since_2.0.2.2B-.29
Issue #4993
The new API emphasizes control over the vCPU data by granting access
through the Vcpu::with_state() method, which makes sure that the vCPU is
stopped, invokes the supplied function with a reference to the VM state
and resumes the vCPU if the function returns true.
The old Vcpu::run(), Vcpu::pause() and Vcpu::state() methods are removed
in favor of the new API. Execution of the vCPU is now interrupted by
sending a native Genode Signal to its Vcpu_handler, which will run the
VMM's exit handling method. When this method retrieves the vCPU state by
calling Vcpu::with_state(), the outside interruption is detected and on
x86 a recall exit is injected into the state to signal the vCPU
interruption / pause request to the VMM's vCPU handler.
Ref #4968
instead via the hardware registers of the FPU. On Genode all components and
so VMMs are built such, that the compiler may generate optimized code by
using the FPU at any time. We had to make sure to save the
FPU state as early as possible before the VMM component touches the FPU,
to avoid corrupting & losing guest FPU state. This caused headache again
and again. To avoid the uncertainty, we remove this feature and explicitly
transfer the FPU state via the UTCB.
Depending on the client and use-case the current minimal timeout
value of 5 ms could be too high, lowering it to 1 ms stays within
the limit imposed by most timer drivers.
Issue #4990.
When the wait value is too small the HALT attempt turnes into
busy-polling in the VMM. To prevent that always wait a minimal
amount of time.
Issue #4990.
This patch removes the obsolete 'io_progress_elem', which was wrongly
enqueued to the 'read_ready_waiters' fifo and not dequeued at
destruction time.
Fixes#4987
