This patch changes the interface of Nitpicker to support dynamically
dimensioned virtual frame buffers. This solves two problems:
First, it enables a client to create a connection to nitpicker without
donating much session quota in advance. The old interface required each
screen-size-dependent client to donate as much memory as needed to
allocate a screen-sized virtual framebuffer. For clients that are
interested int the screen size but cover just a small portion of the
screen (e.g., a banner, a menu, an applet that sits in the screen
corner), this overprovisioning is painful. The new interface allows such
clients to upgrade the session quota for an existing session as needed.
Second, because each nitpicker session used to have a virtual frame
buffer with a fixed size over the lifetime of the session, a client that
wanted to implement a variable-sized window had to either vastly
overprovide resources (by opening a session as large as the screen just
in order to be prepared for the worst case of a maximized window), or it
had to replace the session by a new one (thereby discarding the stacking
order of the old views) each time the window changes its dimensions. The
new interface accommodates such clients much better.
This patch implements the POSIX signal functionality needed to interrupt a
running Noux GDB by pressing 'Ctrl-C'.
It allows to register a signal handler for the 'SIGINT' signal, which
gets executed after 'Ctrl-C' is received from the terminal. With the
current state of the implementation, the signal handler only gets executed
when the Noux application calls a 'read()', 'write()', 'ftruncate()' or
'select()' syscall.
Fixes#923.
With this patch, the 'Ring_buffer' class can be made unsynchronized by
setting the 'Ring_buffer_unsynchronized' policy as third template
argument.
Fixes#922.
USB HID gets stuck due to strange kernel error
as HDMI starts simulatnously. This workaround
delays HDMI init by a second (only in case we
build for Exynos5 & FOC with USB) to let
scenarious like demo get their USB HID started
without much CPU load.
ref #796
For the framebuffer driver of the i.MX53 platform to work even when u-boot
didn't prepared the display previously, there were some IOMUX routes missing.
Fixes#914
By now, only one button press/release event per IRQ was handled correctly.
Pressing and/or releasing several buttons concurrently could bring the input
driver into an inconsistent state.
Fixes#913
* Remove far too low default values from Nic::Connection constructor
* Extend lwip initialization function with desired TX/RX buffer sizes
* Add configuration possibility to libc_lwip_dhcp plugin to define
buffer sizes, like the following:
'<libc tx_buf_size="1M" tx_buf_size="1M"/>'
Fixes#892
Previously, if two ID allocators for different kernel objects had the
same size, the kernel-object framework managed both objects types
through the same allocator instance. This is caused by the use of
unsynchronized singletons in the accessor functions and can be avoided
by creating new types through inheritance instead of using typedefs.
Anyways, this fix is a little bit ugly and should replaced by avoiding
the use of unsynchronized singletons in the future.
fix#906
At this point we cannot close the connection anymore because all
mappings are gone and the needed stack is invalid. This is not a
problem since process will be discarded anyway.
Fixes#909.
With this patch, the register contents of a paused thread (which is not
currently executing a syscall) can get modified by the
'Cpu_session::state()' function.
Fixes#896.
The copy constructor of Signal did not copy the Signal::Data contents of
the copy source. This bug could survive undetected because the compiler
can optimize code in a way, that copy constructor and destructor are not
necessary when returning by value from simple functions. I assume that
it creates the object in CPU registers instead of RAM and reuses it
instead of copying it to save time. This way the bug triggered first
after wait_for_signal was changed in a way that avoided optimization.
ref #912
In hybrid mode, all programs are dynamic executables and ld.lib.so is
not supported. Therefore, only the "static" variant of the test can be
build and executed.
This change allows for the testing of cli_monitor's automatic resource
balancing by executing the following command:
start ram_eater --ram-limit 1G --count 5
The command starts 5 instances of a RAM-eating process, which is,
however, able to yield resources when instructed. The RAM quota for the
processes gets automatically extended because of the overly large limit
of 1 GiB, which is far more than CLI monitor's RAM resources (100 MiB).
When the RAM usage hits the preservation limit, CLI monitor broadcasts
yield requests to each ram_eater instance, which allow the scenario to
remain alive.
