The visibility of the client's view is re-evaluated at each animation
step. However, when the client appears long after the initial
fade-in/out animation is completed, the initial visibility state
remaines unchanged. This happens when booting the Sculpt scenario in
Qemu where the the nit_fb instances of the leitzentrale could not be
started in time. This patch fixes the issue by re-evaluating the view
visibility also at the view-creation time.
We need to update the blueprint pkg path as well in case the start node
is changed. Otherwise the query tool will keep using the initially
configured pkg path.
This patch improves the error handling for the case where the depot
lacks the content of the to-be-deployed pkg. Instead of infinitely
reattempting to obtain blueprints for such content, the deploy tool
prints a single message.
This patch adds two key remappings for the magic keys of the sculpt
scenario. KEY_DASHBOARD toggles the leitzentrale. KEY_RESTART resets
the noux-control subsystem of the leitzentrale.
Issue #2676
If only a single AHCI device is present, the block service provided by
the drivers subsystem allows the client to refer to this block device
via the label 'default'.
Issue #2676
This patch changes the 'depot_deploy' tool to spawn any number of
runtimes. In contrast to the original version, which merely consumed a
blueprint generated by a pre-configured 'depot_query' instance, the new
version actively generates queries as needed. So there is a feedback
loop between 'depot_deploy' and 'depot_query'. The instantiation of
subsystems is controlled by the '<start>' nodes of the 'depot_deploy'
configuration. For each start node, the tool tries to determine the
ingredients (provided by the depot) by asking the 'depot_query' tool.
Once the information is complete, a corresponding start node of the
dynamic init instance is generated.
This patch introduces the subnodes <provides>, <requires>, and
<content> to the <runtime> node. All <rom> sessions that are
expected from the depot appear within the <content> node, which
sets them nicely apart from <rom> sessions that may be required
as runtime arguments.
Note that the <requires> and <provides> nodes do not appear in the
patch because the existing depot_deploy tool does not interpret this
information (the pkg/test-fs_report runtime does not provide any
service, and the timer session is provided as a common route).
This patch adds the config attribute 'query'. If set to the value "rom",
the query information is obtained from a ROM session labeled "query".
Otherwise, the query information is expected to be part of the config.
This enables us to use the component in two different scenarios. In
one scenario, 'depot_query' is embedded in a managed dynamic init.
Here, taking the query from the config is easy. In the other scenario,
'depot_query' is running as a daemon with a once-configured VFS but
varying queries. The queries originate from a component that does not
control the 'depot_query' config.
The new 'Terminal_session::size_changed_sigh' RPC function registers a
signal handler that is triggered each time when the terminal size
changes. It enables the client to adjust itself to the new size by
subsequently calling the 'size' RPC function. Of all terminal servers,
only the graphical terminal triggers this signal.
The 'Buffered_xml' utility is used by three components and a fourth is
on the way. To avoid another duplication of the code, this patch makes
it publicly available at 'os/buffered_xml.h'.
By specifying the 'config' of a '<runtime>' as an attribute, we can
distinguish the case where the config is obtained from a ROM session
from the case where the config is specified inline as a '<config>' node.
The '<dependencies>' attribute 'path' refers to a depot archive.
Depending on the attributes 'source="no"' and 'binary="no" (defaults
shown), the depot_query component determines the source/binary
dependencies of the given archive. The result has the form of a report
with a sequence of <missing> and <present> nodes, each equipped with the
'path' of the dependency.
Since the <query> node results in the generation of a "blueprint"
report, it should better be named <blueprint>. This also clears the way
for adding further query types such as <dependencies>, following the
same pattern of generating a report of the corresponding query name.
