The VFS server used to respond to any invalid config by exiting.
By disregarding such configurations instead, this patch makes the VFS
server robust against temporary malconfiguration.
This commit adapts the aperture splitting between the GPU multiplexer
and the display driver where the former now always tries to reserve
32 MiB of aperture space for itself instead of limiting the space
for the display driver. In case the aperture is not large enough
the display driver takes precedence and the GPU service has to make
do with remaining space. In the worst case that renders the GPU
service unusable.
Issue #5377.
This patch fixes focus-follows-mouse problem reported for Sculpt 24.10
when using no (operational) backdrop.
In the absence of a background, nitpicker wrongly delivered absolute
motion events to the most recently hovered client even after leaving the
client's area to a area occupied by no client. These motion events, in
turn, confused the internal consistency of the window managers
enter/leave tracking.
Fixes#5375
Since the panorama depends on the config, nitpicker needs to re-evaluate
the validity of the pointer position after each reconfiguration. If the
pointer position is no longer visible, pick a new visible one.
Issue #5352
This patch handles the case where a mode change happens in-between
session creation and the registration of the mode-signal handler,
which can result in a sporadic loss of response to mode changes.
Noticed while working on issue #5286.
With the change of "gui_session: provide mode info as XML", the
client-side window-close handling became dysfunct because the
window-close state got wrongly interpreted as initial window state, to
the effect that a client's initial-window size policy got applied
instead of closing the window.
This patch makes the inital state of running a windowed application
(when no window size is defined yet) clearly distiguishable from the
state after which the user closed the window. Prior this patch, both
conditions were reflected by an empty <capture/> node in the panorama.
Now, the latter condition is reported as <capture closed="yes"/>, which
alleviates the need to track the life cycle of a window at the client
size.
Issue #5353
If a <domain> is constrained by 'width' or 'height' attributes, clip
the capture rects of the panorama info reported to the client. So the
client observes the constraint as window size.
Issue #5356
Since #5352, the 'screen_size' RPC function returns a rectangle clipped
against the client's bounding box, which unfortunately prevents
screen-capturing applications from determining the actual screen size.
This patch restores the original behavior by clipping the panorama
against client-specific constraints w/o clipping against the client's
buffer size.
Fixes#5365
This patch resets the pixel buffer shared with the capture client
whenever the capture policy is modified and reports the whole buffer as
affected rectangle on the next client call of 'capture_at'. It also
clips the dirty rectangles tracked via 'mark_as_dirty' against the
bounding box of the capture session to avoid the interference of
out-of-view parts of the panorama with a capture client.
Fixes#5368
Sometimes when removing the popup window in Sculpt's Leitzentrale, a few
residual pixels remained. This is caused by the too strict coupling of
drawing and sync handling, effectively executing the fb-sync handler
repeatedly via 'Main::mark_as_damaged' during 'refresh_view' calls.
This tight coupling has two unwelcome effects. First, the sync handling
is executed more often than needed. Second, the sync handling (and fb
flushing) happens at intermediate states when view-stack changes are
applied (like changing a view geometry).
This patch uses a local signal handler to defer the execution of the
sync code until all drawing has finished.
Issue #5347
Issue #5356
When nitpicker is used as nitpicker client as is the case for Sculpt's
Leitzentrale, the time to sleep was tracked wrongly. The fb sync stays
alive only if a refresh operation is actually issued.
Issue #5347
Issue #5356
Instead of forwarding the whole devices ROM of the platform driver to the
display driver, report only Intel devices and additionally adjust the
reported IOMEM size to the reduced aperture size.
Related #5207
Issue #5345
Issue #5356
Commit ac42ade introduced a regression that triggered an assertion in
`Dhcp_server::free_ip()` because the DHCP allocation was not properly
removed during a domain update. The underlying issue was that
`with_dhcp_server()` silently landed in the `no_dhcp_server_fn`.
Fixes#5364
Inform all GUI clients of a new version of the mode information whenever
the nitpicker configuration is modified. This is needed because changed
capture policies influence the panorama observable by the GUI clients.
Issue #5352
Fixes the following misbehavior: If a global key is pressed (e.g., Caps
Lock in Sculpt) and the mouse is clicked before release, the global-keys
handler receives the global-key press but no further events of the
sequence, especially *no Caps-Lock release*.
A more reasonable fix may address the "else branch" that deletes the
_input_receiver in case of mouse events without a hovered client too,
which is beyond the narrow scope of this fix.
While the focused client has enabled exclusive input, nitpicker does
not translate relative motion to absolute motion but routes relative
motion directly to the client. Additionally, the pointer origin is
forcibly moved to a position outside the screen boundaries, making the
pointer invisible.
Issue #5355
This interface allows a GUI client to express the intent to exclusively
observe relative motion events while locking the absolute pointer
position. This patch merely extends the interface without implementing
it.
As this change touches os/include/input/component.h, it moves the
manage/dissolve operations into the class, ensuring the call of
dissolve at destruction time.
Issue #5355
In multi-monitor scenarios, the mode is no longer a single rectangular
area but a panorama with potentially many captured rectangles. This
patch replaces the former 'mode' and 'mode_sigh' RPC by a new 'info'
ROM accessor.
Issue #5353
Capture clients used to always capture the view stack at the origin of
the coordinate system. So each capture client obtained a mirror of the
same picture. This patch allows for the placement of capture clients on
larger panorama using Genode's usual label-based policy-selection
approach. Thereby, each monitor in multi-monitor scenario can display a
different portion of the panorama.
The patch takes special care to always keep the pointer in a visible
position. The pointer cannot be moved to any area that is not captured.
Should the only capture client displaying the pointer disappear, the
pointer is warped to the center of (any) remaining capture client.
Fixes#5352
The new Framebuffer::Session::sync_source RPC function allows for the
selection of a specific source of sync signals in the presence of
multiple capture clients at the GUI server.
This patch contains only the extension of the interface. The information
is not evaluated by the GUI server yet.
Issue #5347
This patch adds central and safe utilities for accessing the distinct
parts of the virtual framebuffer to relieve clients from pointer
calculations.
Issue #5351
This patch eases the vertical organization of multiple surfaces within
one larger surface, which is the case when keeping front/back buffers
within one compounding GUI buffer.
Issue #5351
Propagate the want of an alpha channel as attribute of Framebuffer::Mode
instead of passing this property as a separate bool argument.
This clears the way for adding useful accessors for pixel/alpha/input
surfaces to the Mode type as a subsequent step.
Issue #5351
By enhancing the Framebuffer::Session interface by the new RPC functions
'blit' and 'panning', GUI clients become able to attain tearing-free
output. Two modes of operations are supported.
1. Atomic back-to-front blitting
GUI clients that partially update their user interface like regular
application dialogs, can now implement double buffering by placing
both the back buffer and front buffer within the GUI session's
framebuffer and configuring a view that shows only the front buffer.
The 'blit' operation allows the client to atomically flush pixels
from the back buffer to the front buffer.
2. Atomic buffer flipping
GUI clients that always update all pixels like a media player or
a game can now use the 'panning' feature to atomically redirect the
displayed pixels to a different portion of the GUI session's virtual
frame buffer. The virtual framebuffer always contains two frames,
the displayed one and the next one. Once the next frame is complete,
the client changes the panning position to the portion containing
the next frame.
Issue #5350
Limit the use of Reg_list::for_each that caches a next pointer
of its items to allow destruction of items in its lambda body.
Instead provide an Reg_list::apply function in addition, which
takes a condition lambda to find the matching item, and a lambda
processed on it. In most use-cases where for_each was used, only
one item was searched for. Here we can use apply now., without
the need for a cached pointer, nor too many iterations.
Fixesgenodelabs/genode#5349
Unless nitpicker is used in 'request_framebuffer' mode, it no longer
depends on a periodic timer but merely acts as a broker between capture
clients and GUI clients. Sync signals as delivered to GUI clients are
now wired to Capture::Session::capture_at calls. So the display driver
defines the occurrence of those signals.
Note that sync signals are only delivered while a driver actively calls
'capture_at'. If a driver stops capturing, GUI clients no longer receive
any sync signal. This is a change from the previous situation where GUI
clients could depend on the periodicity of sync signals.
Issue #5347
With this change, a client (i.e., display driver) can register
a wakeup signal handler to be notified on the arrival of new data to
capture. The signal is delivered only when the client has stopped
capturing. The client propagates this condition to the server using
the new 'capture_stopped' RPC call.
This change in principle enables a display driver to suspend its
periodic mode of operation after a few frames without capturing any
new data. As the first driver, the fb_sdl driver has been adapted to
the new protocol. This change not only eliminates the driver's CPU
load when idle, it also reduces the latency of sporadic output
because the response to such GUI updates is no longer bound by a
fixed periodic interval.
Issue #5344
This patch is a preparatory step for relaxing the strictly periodic
operation of fb_sdl. With the new design, the SDL event loop can block
for events while Genode's main entrypoint stays receptive for I/O.
The main entrypoint can interact with the SDL thread by injecting
SDL user events.
The patch also replaces the full-screen clearing and update of the
SDL window by an update of the captured bounding box only. This reduces
the CPU load of fb_sdl when idle. When updating a small part of the
screen (e.g., when moving the mouse only), the load is still rather
heavy though.
Issue #5344
