This is a follow-up fix for commit "sculpt: apply Dialog API to diag,
panel, and graph", which happened to render the legacy dialogs (network
and settings) inaccessible.
The patch avoids the use of clack seq numbers for the 'popup_opened'
condition (which happens on click, not clack). It also overrides old
click information on the arrival of a new click, avoiding the evaluation
of stale click sequence numbers in distant_runtime.cc. Furthermore, it
reduces the rate of 'Distant_runtime::_try_handle_click_and_clack'.
Issue #5008
On WPA3 encrypted networks the AP picker does not indicate encryption
and does not prompt for a passphrase.
Also indicate an encrypted network when "protection=WPA3", remedying
both issues.
Fixes#5022
Up to now, when using force_*, all other configured modes of a connector
got overwritten and the force_* got enforced. With the commit,
the connector mode is considered (if below max_*) and the resulting
framebuffer may be larger then the dimension of force_*.
Without this change gpg aborted with
gpg: Sorry, no terminal at all requested - can't get input
and after adding --batch onlye with
gpg: signing failed: File exists
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.
