The base handle for layouts in libxkbcommon is an index. Let's follow
this notion in our API to set/get layout, instead of using it's name as
an ID.
On the way, do cleanup. Following methods are removed as not needed any
more:
- Xkb::layoutShortNames()
- Xkb::layoutNames()
If user set custom name for the layout, country flag is not displayed.
Instead, Display Name is shown in the applet.
This reveals shortcomings in current DBus API design.
We need more data to pass over DBus to fix this.
Then, multiple improvements are possible:
- fix aforementioned bug
- add flags to context menu
- display correct translated Layout Name in the context menu
- simpler, cleaner DBus API and applet implementation
- etc.
At the moment we are getting the input method from the command line
which is not very handy (but very secure).
This patch changes it so it can be specified from a configuration
setting.
CCBUG: 427972
If the maximizedChanged connection is queued, several configure events
will be sent. If the client acks the first configure event and later on
acks the second one, the maximize animation will be cancelled due to
"unexpected" geometry change.
Based on the code, there is no clear reason why the connection is queued
in the first place.
CCBUG: 431415
The last presentation timestamp might be in the future by a couple of
hundred microseconds.
This may break timestamp aligning code because it assumes that the
last presentation timestamp is less or equal to the current time.
In order to properly handle this case, we have to first compute the
next expected presentation timestamp by advancing the last presentation
timestamp by the amount of vblank interval. If that fails, we can safely
resort to aligning timestamps.
BUG: 431509
BUG: 431449
This logs to a tracefs filesystem which can be viewed in tools such as
gpuvis to see precise timings of activities in relation to other trace
markers in X or graphic drivers.
This patch is loosely based on D23114. Though modified with thread
safety, support for string building, and a RAII pattern for durations.
Ultimately that expanded it somewhat.
This reverts commit bf5155f82b.
Maximize and minimize function hints provided by some applications are
bogus. This in its turn breaks video games that minimize themselves when
they loose input focus.
Ideally, the window manager should not be concerned about Motif hints
provided by NetWM applications as they set the window type.
BUG: 431450
Qt 5.15 introduced new syntax for defining Connections. Fix warnings like this one:
QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
follow up of d2f3372749
With the new compositing scheduling, we want the screen to be redrawn as
close as possible to the next vblank. Furthermore, compositing is no
longer driven by a timer. This change removes the NoSwapEncourage swap
strategy as it doesn't make sense now, in addition to that it just does
not work on Wayland.
Windows have two kinds of repaints - window repaints and layer repaints.
The main difference between the two is that the former is specified in
the window-local coordinates while the latter is specified in the global
screen coordinates.
Window repaints are useful in case the position of the window doesn't
matter, for example for repainting damaged regions, etc.
But its biggest issue is that with per screen rendering, it's not
possible to determine what screens exactly have to be repainted. The
final area affected by the window repaint will be known only at
compositing time. If a window gets damaged, we have to schedule a
repaint on ALL outputs. Understandably, this costs a little bit in terms
of performance.
This change replaces the window repaints with the layer repaints. By
doing so, we can avoid scheduling repaints on outputs that don't
intersect with the dirty region and improve performance.
If there is a pending frame, the RenderLoop will delay all schedule
repaint requests to the next vblank event. This means that the render
loop needs to be notified when a frame has been presented or failed.
At the moment, the RenderLoop is notified only about successfully
presented frames. If some frame fails, no repaints will be scheduled
on that output.
In order to make frame scheduling robust, the RenderLoop has to be
notified if a frame has failed.
Currently, we estimate the expected render time purely based on the
latency policy.
The problem with doing so is that the real render time might be larger,
this can result in frame drops.
In order to avoid frame drops, we need to take into account previous
render times while estimating the next render time. For now, we just
measure how long it takes to record rendering commands on the CPU.
In the future, we might want consider using OpenGL timer queries for
measuring the real render time, but for now, it's good enough.
