This is a drivers subsystem that starts the most fundamental
(framebuffer, input, block) device drivers dynamically, depending on the
runtime-detected devices. The discovered block devices are reported
as a "block_devices" report.
This patch applies the handling of cursor keys, function keys, and page
up/down keys even if no keymap is defined. This is the case when using
the terminal with character events produced by the input filter.
Add a "writeable" policy option to the ahci_drv and part_blk Block
servers and default from writeable to ready-only. Should a policy
permit write acesss the session request argument "writeable" may still
downgrade a session to ready-only.
Fix#2469
When idle, menu_view de-schedules timer events to save processing time.
Once reactivated by a dialog update, it computes the passed time and
applies the result to the animator. However, the animation was most likely
started by the update not during the sleep. So the passed time must not
be applied to the animation in this case. Otherwise, many animation steps
are computed at once within a single visible frame.
Furthermore, the patch adjusts the REDRAW_PERIOD to 2, which is a better
value for geometric movements as opposed to mere color-blending effects
where the frame rate does not matter so much.
It also refines the nitpicker-buffer relocation in a way that extends
the buffer but does not shrink it. This lowers the interaction with
nitpicker in situations where the dialog size changes a lot.
By applying the text output to the alpha buffer in addition to the pixel
buffer, labels can now appear without the need for an underlying frame
or button.
The new widget allows one to align a child widget within a larger parent
widget by specifying the boolean attributes 'north', 'south', 'east',
and 'west'. If none is specified, the child is centered. If opposite
attributes are specified, the child is stretched.
This improves the output quality of antialiased lines onto a transparent
nitpicker buffer. For antialiased graphics operations, the initial color
leaks through. Leaking 50% gray is better than leaking black, in
particular when drawing white lines.
This patch makes the use of 'List' invisible at the 'Animator'
interface. This allows users of the utility to keep 'Animator::Items' in
a custom 'List' with no aliasing problems.
The VFS library can be used in single-threaded or multi-threaded
environments and depending on that, signals are handled by the same thread
which uses the VFS library or possibly by a different thread. If a VFS
plugin needs to block to wait for a signal, there is currently no way
which works reliably in both environments.
For this reason, this commit makes the interface of the VFS library
nonblocking, similar to the File_system session interface.
The most important changes are:
- Directories are created and opened with the 'opendir()' function and the
directory entries are read with the recently introduced 'queue_read()'
and 'complete_read()' functions.
- Symbolic links are created and opened with the 'openlink()' function and
the link target is read with the 'queue_read()' and 'complete_read()'
functions and written with the 'write()' function.
- The 'write()' function does not wait for signals anymore. This can have
the effect that data written by a VFS library user has not been
processed by a file system server yet when the library user asks for the
size of the file or closes it (both done with RPC functions at the file
system server). For this reason, a user of the VFS library should
request synchronization before calling 'stat()' or 'close()'. To make
sure that a file system server has processed all write request packets
which a client submitted before the synchronization request,
synchronization is now requested at the file system server with a
synchronization packet instead of an RPC function. Because of this
change, the synchronization interface of the VFS library is now split
into 'queue_sync()' and 'complete_sync()' functions.
Fixes#2399
The launcher.run scenario was last updated mid-may of the recently
developed cap-quota accounting (before all cap types were covered).
Hence, the quotas used in the scenario are too low. This patch adjusts
the values such that the scenario can be started on NOVA on Qemu. It
also fixes a warning about a deprecated way of configuring the
report_rom component.
Thanks to Jörg-Christian Böhme for reporting!
This patch changes the noux build rules to produce a tar archive in
'bin/', alleviating the need for this step from the run scripts.
This way, the visible result of a built noux package is a single (tar)
file in '<build-dir>bin/', which is suited for the use as a ROM module.
With the capability-quota mechanism, the terminal-session won't always
be constructed completely on the first try (we may run out of caps in
the middle of the construction). Therefore, all members of the object
must be properly destructable. Furthermore, the patch replaces the
sliced heap by a heap to avoid allocating a new dataspace for each line
of the cell array.
Previously, the Genode::Timer::curr_time always used the
Timer_session::elapsed_ms RPC as back end. Now, Genode::Timer reads
this remote time only in a periodic fashion independently from the calls
to Genode::Timer::curr_time. If now one calls Genode::Timer::curr_time,
the function takes the last read remote time value and adapts it using
the timestamp difference since the remote-time read. The conversion
factor from timestamps to time is estimated on every remote-time read
using the last read remote-time value and the timestamp difference since
the last remote time read.
This commit also re-works the timeout test. The test now has two stages.
In the first stage, it tests fast polling of the
Genode::Timer::curr_time. This stage checks the error between locally
interpolated and timer-driver time as well as wether the locally
interpolated time is monotone and sufficiently homogeneous. In the
second stage several periodic and one-shot timeouts are scheduled at
once. This stage checks if the timeouts trigger sufficiently precise.
This commit adds the new Kernel::time syscall to base-hw. The syscall is
solely used by the Genode::Timer on base-hw as substitute for the
timestamp. This is because on ARM, the timestamp function uses the ARM
performance counter that stops counting when the WFI (wait for
interrupt) instruction is active. This instruction, however is used by
the base-hw idle contexts that get active when no user thread needs to
be scheduled. Thus, the ARM performance counter is not a good choice for
time interpolation and we use the kernel internal time instead.
With this commit, the timeout library becomes a basic library. That means
that it is linked against the LDSO which then provides it to the program it
serves. Furthermore, you can't use the timeout library anymore without the
LDSO because through the kernel-dependent LDSO make-files we can achieve a
kernel-dependent timeout implementation.
This commit introduces a structured Duration type that shall successively
replace the use of Microseconds, Milliseconds, and integer types for duration
values.
Open issues:
* The timeout test fails on Raspberry PI because of precision errors in the
first stage. However, this does not render the framework unusable in general
on the RPI but merely is an issue when speaking of microseconds precision.
* If we run on ARM with another Kernel than HW the timestamp speed may
continuously vary from almost 0 up to CPU speed. The Timer, however,
only uses interpolation if the timestamp speed remained stable (12.5%
tolerance) for at least 3 observation periods. Currently, one period is
100ms, so its 300ms. As long as this is not the case,
Timer_session::elapsed_ms is called instead.
Anyway, it might happen that the CPU load was stable for some time so
interpolation becomes active and now the timestamp speed drops. In the
worst case, we would now have 100ms of slowed down time. The bad thing
about it would be, that this also affects the timeout of the period.
Thus, it might "freeze" the local time for more than 100ms.
On the other hand, if the timestamp speed suddenly raises after some
stable time, interpolated time can get too fast. This would shorten the
period but nonetheless may result in drifting away into the far future.
Now we would have the problem that we can't deliver the real time
anymore until it has caught up because the output of Timer::curr_time
shall be monotone. So, effectively local time might "freeze" again for
more than 100ms.
It would be a solution to not use the Trace::timestamp on ARM w/o HW but
a function whose return value causes the Timer to never use
interpolation because of its stability policy.
Fixes#2400
