The 'Timer::Session::trigger_periodic' RPC function used to accept 0 as
a way to de-schedule the periodic processing. Several components such as
nitpicker relied on this special case. In "timeout: rework timeout
framework", the value of zero was silently clamped to 1, which has the
opposite effect: triggering signals at the maximum rate. This results in
a visible effect in Sculpt where the leitzentrale-nitpicker instance
produces a constant load of 2% CPU time.
This patch restores the original timer semantics by
- Documenting it in timer_session.h,
- Handling the case explicitly in the timer implementation, and
- Replacing the silent clamping of the unexpected value 0 passed
to the timeout framework by a diagnostic error message.
Issue #3884
This patch restores the ability to launch nitpicker within a gui_fb
window. It is a follow-up fix for "nitpicker: make framebuffer and input
optional".
Issue #3812
This patch enables sculpt to utilize the CPU reset mechanism via the
PS/2 controller as well as the information provided via the ACPI FADT
information. Whenever the /config/system file is changed to <system
state="reset"/>, both mechanisms are triggered.
Supporting both mechanisms is useful because the PS/2-based reset does
not work reliably on modern machines. The PS/2-based reset is useful in
the case when the FADT reset information refers to the PS/2 command
port. In this case, the platform driver is unable to access this port
because it is already handed out to the PS/2 driver. In this case, the
PS/2 driver kicks in.
Issue #2726
If 'system="yes"' is specified in the <config>, the platform driver now
monitors the content of the system ROM. Should the value become "reset",
a reset is triggered using information obtained from the ACPI driver.
Related to issue #2726
The change of the platform driver is needed to avoid a parsing error of
the ACPI ROM when encountering an unexpected <reset> node.
Thanks to Alexander Boettcher for the preventing the regression of #3829
and improving the adherence to the ACPI spec when parsing the reset type.
Related to issue #2726
This patch adds the handling neccessary for clients to upgrade the cap
quota of their GUI session. Until now, the upgrade mechanism supported
only RAM quota.
The limitation became visible once a client - in the particular case the
motif_decorator - attempted the cap upgrade of its GUI session. The cap
quota would arrive at the wm, but the wm would keep it instead of
forwarding the quota to nitpicker. This resulted in an infinite retry
loop at the motif_decorator, ultimatedly depleting all its cap quota.
The window manager infers the overall state from the intercepted input
events for the decorator and all GUI clients. However, each of those
parties have an independent input-event stream. Whereas the order of
events within one GUI session is strict, the order of events between GUI
sessions is arbitrary. The window manager wrongly relied on a global
event ordering to track the pointed-at GUI session.
The patch removes the assumption of a global event order by tracking the
relevant pointer state for each GUI session independently and evaluating
these states when propagating the pointer position to the decorator.
Fixes#4059
This commit modified bash's builtin mapping of character sequences to
readline-functionality to detect the sequence of the delete symbol as
generated by the terminal.
Fixes#4058
The commits adds the same configuration values as supported up to now by
the monolithic usb driver. In contrast to the original, by default all drivers
are started. Disabling a controller type is used by Sculpt, e.g. for OHCI if
running Sculpt inside Virtualbox.
The addition of further keyboard layouts would otherwise pollute the
config/ directory too much.
Caution: When updating Sculpt OS, don't reuse your existing
config/event_filter file unmodified! You need to replace the chargen
includes, pointing to the new location, e.g.,
<include rom="en_us.chargen"/>
<include rom="special.chargen"/>
must be changed to
<include rom="keyboard/en_us"/>
<include rom="keyboard/special"/>
Issue #4055
This patch extends the settings dialog with the ability to select the
keyboard layout between the options that are included in the sculpt
image. The manual configuration is of course still possible by editing
the /config/event_filter directly.
If both the fonts configuration and the event-filter configuration are
managed manually, the settings button and window are not displayed.
Fixes#4055
By sorting the reported output, all consumers of the reports become able
to rely on a deterministic order. For example, the file browser of
Sculpt OS, the launcher menu items, and the depot-selection items will
appear in a predictable order.
Fixes#4054
This patch adds session-routing options to connect components to the
capture/event interfaces of the global nitpicker GUI server or the
leitzentrale GUI server. It thereby enables the implementation of screen
capturing components, remote management tools, or virtual keyboards.
Since those services are very powerful, they are subsumed under the
"hardware" category of the component graph as opposed to the GUI
category, which guarantees the separation of clients.
Fixes#4053
This patch adds 4 priority levels to the runtime subsystem. The highest
priority is used for components that are critical for the operation of
Sculpt, in particular the Leitzentrale GUI. All regularly deployed
components are assigned the lowest priority by default.
With priorities available in the runtime subsystem, this patch flattens
the priority levels at the top-level init to only two levels and
overlays the priority bands of the drivers, leitzentrale, and runtime
subsystems into one priority band. This has three benenfits:
- This change prevents the starvation of the Leitzentrale GUI from a
spinning high-priority driver (issue #3997).
- The change will also ease the hosting of latency-critical components
in the runtime subsystem that are prioritized higher than regular
components, the storage stack, and the network stack.
- The Leitzentrale GUI remains always perfectly responsive regardless
of the workloads deployed from packages. In the previous version,
the runtime graph was sometimes stuttering on high system load.
Issue #4045
