At the calculation of the first FPS, gears has initialized last
FPS time with gettimeofday().
But the callback_data passed in the callback of wl_surface_frame()
is the current time, in milliseconds, with an undefined base.
Because of this subtracting last FPS time from callback_data makes no sense.
For example, below is the result of running weston-gears on weston with
drm backend:
$ weston-gears
Warning: FPS count is limited by the wayland compositor or monitor refresh rate
1 frames in 1094460.125 seconds = 0.000 FPS
301 frames in 5.016 seconds = 60.008 FPS
301 frames in 5.016 seconds = 60.008 FPS
301 frames in 5.016 seconds = 60.008 FPS
As you can see, the the first FPS value is something odd.
This patch fixes it by initializing last FPS time with the callback_data passed in
the first callback.
Reviewed-by: Nils Chr. Brause <nilschrbrause@gmail.com>
This option is so we can disable showing any panel at all. The default
is to continue showing the panel and no example is added to weston.ini
because it's an uncommon request.
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Currently, there is a fun flicker when toggling maximization or
fullscreen on a window in mutter or more sophisicated compositors
and WMs.
What happens is that the client want so go maximized, so we
calculate the size that we want the window to resize to (640x480),
and then add on its margins to find the buffer size (+10 = 660x500),
and then send out a configure event for that size. The client
renders to that size, realizes that it's maximized, and then
says "oh hey, my margins are actually 0 now!", and so the compositor
has to send out another configure event.
In order to fix this, make the the configure request correspond to
the window geometry we'd like the window to be at. At the same time,
replace set_margin with set_window_geometry, where we specify a rect
rather than a border around the window.
In many clients of weston, Display was not being destroyed so added it.
Also destroy windows, widgets which were not being destroyed.
Signed-off-by: vivek <vivek.ellur@samsung.com>
Reviewed-by: Pekka Paalanen <ppaalanen@gmail.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
This allows for easily testing a compositor's damage tracking in all
currently available configurations including wl_surface.buffer_transform,
wl_surface.buffer_scale, and wl_viewport. It also includes a
--rotating-damage that flag instructs the client to change the
wl_surface.buffer_transform on every commit. This tests the compositor for
proper handling of texture uploads even when the transform has changed but
the buffer size hasn't.
Once we've updated the window state and scheduled a resize, we know that
the next frame we send to the compositor will match the configured state.
This means we can just ack the configure immediately and not jump
through hoops to try to do it from the redraw stage.
As the protocol says, the states determine how the width and height
arguments should be interpreted, so it makes logical sense to do the
interpretation after.
Add a new state_changed_handler callback to the window to know when the
window has changed state; the terminal will use this to know when the
window started and ended its resize operation, and modify the terminal's
titlebar accordingly.
Currently, there's a race condition. When resizing from the left, and
a client attaches a buffer after the resize ends, you suddenly see the
buffer jump to the right, because the resize ended while multiple
attaches were in-flight. Making resize a state can fix this, as the
server can now know exactly when the resize ended, and whether a commit
was before or after that place.
We don't implement the correct tracking in this commit; that's left as
an exercise to the reader.
Additionally, clients like terminals might want to display resize popups
to display the number of cells when in a resize. They can use the hint
here to figure out whether they are resizing.
The states system, so far, has been a complicated mix of weird APIs
that solved a real race condition, but have been particularly ugly
for both compositors and clients to implement.
It's a confusing name that comes from the ICCCM. The ICCCM is best
forgotten about.
With the addition of the potential new "transient" role meaning a
parent-relative toplevel like a long-lived popup, used for e.g.
tooltips, the set_transient_for name will become even more confusing.
xdg-shell mandates that the FULLSCREEN state means that we must match
the size that we were configured to, at least by default. Other states
or protocol extensions might relax this requirement, but at least for
now implement the behavior specified in the protocol documentation.
Toytoolkit was not designed to handle input from subsurfaces and
instead it expects subsurfaces to have an empty input region. That way
input events for subsurfaces are generated on the main surface and
there is no need to convert coordinates before reporting the event to
the user.
However it is possible that a subsurface has a non-empty input region,
but in that case those events aren't properly processed. The function
window_find_widget() assumes the coordinates are in the main surface
coordinate space, and ends up chosing the wrong widget.
This patch changes the input code to completely ignore input events from
subsurfaces. This option was chosen instead of ensuring that the input
region on those surfaces is always empty since there's no enforcement
that a subsurface should completely overlap with the main surface. If
an event happens in the area of the surface that doesn't overlap, the
event could cause a completely unrelated surface to be picked.
https://bugs.freedesktop.org/show_bug.cgi?id=78207
The calculation off the vertical offset between the widget coordinates
and where the text was rendered was wrong. It was using the constant for
horizontal offset for that too.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=78411
Filter sampling outside the source image can leak black into the edges
of the
desktop image. This is most easily seen by scaling the default tiled image
with this weston.ini:
# no background-image and no background-color
background-type=scale-crop
If simple-touch ran on a compositor with multiple seats, and the first
one happened to have the touch capability while the second one didn't,
the handler for seat capabilities would destroy the wl_touch device it
created on the first call for the first seat when it was called a again
for the second seat that has not touch capabilities.
Fix this problem by creating a separate struct for each seat.
https://bugs.freedesktop.org/show_bug.cgi?id=78365
Quells warning:
clients/keyboard.c: In function ‘keyboard_handle_key.isra.5’:
clients/keyboard.c:556:11: warning: ‘label’ may be used uninitialized in
this function [-Wuninitialized]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Ideally, we'll update the key event handling to deliver events to widgets,
but in the meantime, just blocking key event delivery while a grab is
active goes a long way.
This ensures the allocation results are checked for NULL (out of
memory), and terminates the program in such a case.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
It looks like the handler for frame events from the wl_touch interface for
widgets may have been erroneously copied from the cancel handler so that it
removes all handlers as they are processed. I don't think this makes much sense
for the frame event. This was stopping the panel icons from being pushable with
touch events when using libinput since commit 1679f232e5. All that commit
does it make it start sending the frame events.
Previously we would only use the set background color if the
background-image value was explicitly set to empty or a non-existing
image. With this change, we only load the default background image
if there's no configure background image or background color. In case
of both an image and a color, the image takes precedence as before.
The editor will now insert new lines and tabulations when
pressing the corresponding keys on the virtual keyboard.
The Up and Down arrows can be used to navigate through
lines.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=77496
Signed-off-by: Manuel Bachmann <manuel.bachmann@open.eurogiciel.org>
The "symbols" modifier key of weston-keyboard is no longer
inactive, but will provide an additionnal layout with
numerals and special characters.
Fix the Arabic keyboard, which was rendering out of the
bounds, and now use the Arabic IBM PC keyboard as a
reference for its standard and new symbols layouts.
https://bugs.freedesktop.org/show_bug.cgi?id=71757
Signed-off-by: Manuel Bachmann <manuel.bachmann@open.eurogiciel.org>
weston-terminal uses RLE (U+202B) as a placeholder of the right half
of a double width character. However, not all fonts include this
glyph and cairo renders it as .notdef (glyph index 0) in that case.
There was an issue recently in screen-share.c where config.h was not
being included, resulting in the wrong definition for off_t being used on
32 bit systems. I checked and I don't think this problem is happening
elsewhere, but to help avoid this sort of problem in the future, I went
through and made sure that config.h is included first whenever system
headers are included.
The config.h header should be included before any system headers, failing
to do this can result in the wrong type sizes being defined on certain
systems, e.g. off_t from sys/types.h
Signed-off-by: Andrew Wedgbury <andrew.wedgbury@realvnc.com>
The subsurface widgets on the nested example aren't using Cairo to
render so we should turn it off to prevent the toy toolkit from
creating a redundant extra surface for it. This is particularly
important since Mesa commit 6c9d6898fdfd7e2 because the surface that
the toolkit tries to create is zero-sized and that patch prevents that
from working. This was causing weston-nested to crash.
When adding a subsurface (to display a tooltip) in toytoolkit,
we now get the parent window surface type (SHM or EGL) and
define the new surface type as the same.
This fixes crashes with tooltips in cases like having
Cairo-EGL available but running the X11 compositor.
Signed-off-by: Manuel Bachmann <manuel.bachmann@open.eurogiciel.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
