So that we can test the per-surface ZERO_COPY flag:
- start Weston on DRM backend
- run ./weston-simple-egl -o (need to be opaque to end up on overlay)
- hit debug key 'V' to enable the (broken) hw overlays
The debug key is used by first hitting Mod+Shift+space, then hitting 'v'.
Enabling overlays should change the flags from 0x7 to 0xe. To verify the
window is really on an overlay, use debug key 'S' to tint all
GL-composited things green.
This patch is not intended for upstream.
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Decode the new feedback flags.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
wl_display_dispatch() just dispatches events that are in
default and display queues and if there are no events,
then it will wait for them. But only dispatching
the events doesn't guarantee that we got all the global announcements,
we need to do sync too. Therefore use wl_display_roundtrip() instead
of wl_display_dispatch().
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- introduces ivi-shell-user-interface.c
This is launched from hmi-controller by launch_hmi_client_process and
invoke a
client process.
The basic flow is as followed,
1/ process invoked
2/ read configuration from weston.ini.
3/ draw png file to surface according to configuration of weston.ini
4/ all parts of UI are ready. request "UI_ready" to draw UI.
5/ Enter event loop
6/ If a surface receives touch/pointer event, followings are invoked
according
to type of event and surface
6-1/ If a surface to launch ivi_application receive touch up, it execs
ivi-application configured in weston.ini.
6-2/ If a surface to switch layout mode receive touch up, it sends a
request,
ivi_hmi_controller_switch_mode, to hmi-controller.
6-3/ If a surface to show workspace having launchers, it sends a
request,
ivi_hmi_controller_home, to hmi-controller.
6-4/ If touch down events happens in workspace,
ivi_hmi_controller_workspace_control is sent to slide workspace.
When control finished, event:
ivi_hmi_controller_workspace_end_control
is received.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Just changes some places where a malloc failure is unhandled
to our xmalloc function that exit()s a little more gracefully.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
When ending a drag in the window the cursor will be wrong until the mouse
is moved again. This is because the item being dragged isn't added
until after the enter event.
Also, when picking up an item while moving the mouse the cursor can switch
back to a non-drag cursor before the drag begins. This is because of a
slight delay between button click and drag start.
Finally picking up or dropping an item under a second pointer could cause
that pointer to have the wrong cursor.
Closes one of the issues in bug 56298
https://bugs.freedesktop.org/show_bug.cgi?id=56298
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Explain carefully why we need two roundtrips, not just one, not just
dispatch and roundtrip, but two roundtrips after creating the
wl_registry object.
v2: Explain what initial events are, and that this is a general
technique.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
There are a number of invalid read errors reported by valgrind of the
form:
==13428== Invalid read of size 4
==13428== at 0x405656: advect (smoke.c:116)
==13428== by 0x405E80: redraw_handler (smoke.c:228)
==13428== by 0x40DE74: widget_redraw (window.c:3995)
==13428== by 0x40E02D: surface_redraw (window.c:4053)
==13428== by 0x40E0C9: idle_redraw (window.c:4082)
==13428== by 0x410FC9: display_run (window.c:5561)
==13428== by 0x406518: main (smoke.c:373)
==13428== Address 0xb2c9b14 is 4 bytes after a block of size
160,000 alloc'd
==13428== at 0x4C29DB4: calloc
==13428== by 0x40646B: main (smoke.c:360)
This results in invalid rendering when running a debug version of the
application.
Fix the issue by limiting the maximum values of px and py to 1.5 less
than width and height. This prevents reading past the end of the source
buffer.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82287
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Committing to an xdg_surface with a NULL buffer is currently illegal in
the mutter implementation, so this simply causes the client to error and
exit.
It seems the reason the client did this was so it could add its own
frame callback, but toytoolkit actually provides accurate everything we
need. Just use its functions instead to get the time and schedule a
redraw.
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This started as a copy of simple-shm.c before it was converted to
xdg_shell.
This demo excercises the presentation feedback interface in five
different modes:
- A continuous repaint loop triggered by frame callbacks, and using
immediate commits, just gathering presentation feedback and computing
some time intervals for statistics.
- The same as above, except with 1s sleep before actually repainting as
a response to frame callback. This tests how well the compositor can
do a repaint from idle state (not continuously repainting), assuming
nothing else is causing repaints.
- A continuous repaint loop triggered by 'presented' events rather than
by frame callbacks. If Weston uses an appropriate scheduling
algorithm, this mode achieves the smallest possible frame latency
(below one output refresh period).
In all modes, all frames are pre-rendered at startup, so no rendering
happens during the animation.
[Louis-Francis Ratté-Boulianne: split queuing feature]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
When a toytoolkit client redraws, the toolkit syncs the parent and
geometry. If a client redraws often (such as the terminal drawing a huge
amount of output), this can spam the compositor with requests and may
result in the client's eventual being killed.
We don't need to send requests for changing the geometry or parent if
these haven't changed. So remember the last geometry and parent, and
update them only if needed.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83297
Signed-off-by: Ondřej Majerech <majerech.o@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This reverts the parts of commit 81ff075bf4
that touch window.c.
This brings the toytoolkit window context menus back, until someone
implements the xdg-shell equivalent in the compositor.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82972
Acked-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
If a cursor was set with wl_pointer.set_cursor but not in combination
with an action that has the side effect of damaging the region where the
cursor is positioned, it would not be drawn. This patch explicitly
schedules a repaint of the pointer sprite when it is set.
clickdot is updated to illustrate the bug; when moving the pointer over
clickdot, the pointer is hidden. When not having moved the pointer for
500 ms it is made visible using wl_pointer.set_pointer.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Toytoolkit resets the opaque region which was set manually using the
wayland protocol directly, so use the widget API instead.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The experimental versioning has not been updated when it was supposed
to. Let's try to be better at it now, as xdg-shell is close to have its
first stable version.
Bump the version now to bring the world into the same exact version.
There may be some protocol changes still coming, but we try to land them
before 1.6 gets out. Those changes will bump the experimental version
again as needed.
When 1.6.0 is released, the experimental version will no longer be
bumped, and no incompatible protocol changes will be made. Xdg-shell.xml
file will move to Wayland in 1.7.0, drop the experimental versioning,
and become stable.
Cc: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The master copy of calculate_edges() lives nowadays in gl-renderer.c.
Copy it verbatim from gl-renderer.c into cliptest.c.
Update cliptest.c for the following changes that happened in Weston
core, vertex.clipping.c, and gl-renderer.c:
- replace GLfloat with float
- introduction of weston_view, here replacing weston_surface
- API change of weston_view_to_global_float
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
These symbols (xkb_map_* and others) were replaced in xkbcommon with more
consistent names. See the header xkbcommon/xkbcommon-compat.h for how
the old names map to the new.
The new names have been available since the first stable xkbcommon
release (0.2.0).
Signed-off-by: Ran Benita <ran234@gmail.com>
Prevent attempting to draw the intersection polygon when it contains no
vertices.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
Bryce Harrington
Pekka Paalanen
Marek Chalupa
Nobuhiko Tanibata
Derek Foreman
Frank Binns
Jasper St. Pierre
kabeer khan
Xiong Zhang
Olivier Blin
Ondřej Majerech
Bill Spitzak
Jonas Ådahl
Xiong Zhang
Arnaud Vrac
Ryo Munakata
Ondřej Majerech
Ran Benita
Jonny Lamb
Magnus Hoff
Boyan Ding