Differences in TAR archive member metadata results in unstable depot
hashes. The following properties have to be fixed: modification time
(incl. time zone), numeric owner and group, permission modes.
Releated to #2842
This change allows for the hosting of system-management components
in Sculpt's runtime. The special role must be declared either as
<launcher managing_system="yes"> attribute or in the deploy
configuration's <start managing_system="yes"> attribute.
Issue #5009
Rename locally extended VCPU state from State to Vcpu_state for clarity.
The local namespace only adds two accessor methods, which does not
justify a local generic name.
Ref #4968
Make naming across architectures coherent by renaming Vm_state to
Vcpu_state, to reflect that it contains the state of a Vcpu and not that
of an entire VM.
Ref #4968
Per Affinity::Location a system control cap can be requested. The capability
provides an RPC interface to request and set Cpu_state, as provided by the
former Pd::managing_system(Cpu_state) method. Invocation of those system
control capabilities then *can* (see below) be executed on the desired CPU
as described by Affinity::Location.
The system control cap will be invalid for kernels that don't support
system_control/managing_system functionality at all.
The system control cap will be ever by the same, e.g. ignoring the
Affinity::Location parameter, if the used kernel doesn't support or doesn't
require the feature to execute the system control per CPU.
The commit is a preparation step to add guarded and selective x86 MSR
access per CPU.
Fixes#5009
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
