Data device interface in client just handle with pointer's dnd.
If a touch screen trigger dnd, it will use pointer struct like i
nput->sx, input->sy, input->pointer_focus. So if pointer is moving
when touch screen trigeer a dnd, wrong behaviore will occur.
Before touch screen start dnd, system call touch_grab()
to mark the following drag and drop operation is generated by
touch screen.
Defined some common variables in struct input to track dnd.
Note, touch screen and pointer can't generate drag and drop at the
same time, becuae data device protocol can't identify the drag
and drop event is generated by touch screen or pointer.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Kristian Hogsberg <hoegsberg@gmail.com>
Adding the interface for touch screen event in clients/dnd.c, once
user touch down on this app, it will trigger a touch and drag
operation.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Kristian Hogsberg <hoegsberg@gmail.com>
It seems that this was only used by the popup menu infrastructure,
which can handle this all on its own. Implementing e.g. transients
in the future can be done with a simple xdg_shell_set_transient_for.
We used to ungrab first to stop any existing grab and then grab after
showing the menu. That was broken in c680e90489, which
moved the ungrab down below the grab, and as a result menus are now
shown without a grab. This commit moves the grab back up.
when output is removed, weston-desktop-shell should destroy panel
and background surface on destroyed output.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
The decorations tiles start to overlap and look weird if we go below
200x200 size windows. Just set that as a minimum size if the app
doesn't provide a bigger minimum size.
https://bugs.freedesktop.org/show_bug.cgi?id=66794
cairo_egl_device_create(), which is called next,
already checks if EGL_KHR_surfaceless_context is
available. If not, it fallbacks to pbuffer.
Signed-off-by: Adrian Negreanu <adrian.m.negreanu@intel.com>
And check if the renderer supports the RGB565 format for wl_shm buffers
before creating the cairo surface and requesting the buffer.
It can save quite some memory with big surfaces such as desktop
backgrounds.
For the sample clients we introduce xmalloc() to simplify OOM-handling.
This patch only converts a few callsites, but this will be our strategy
going forward.
It is possible to receive a motion event that was generated by the
compositor based on a pick of a surface of old dimensions. This was
triggerable on toytoolkit clients when minimising. The new window
dimensions were propagated through the widget hierarchy before the event
was dispatched.
This issue was triggering a segfault due to the focussed widget being
lost as the client code tried to identify which widget should have the
focus using co-ordinates outside the dimensions of the surface.
https://bugs.freedesktop.org/show_bug.cgi?id=66795
Originally window.c was requesting version 1 but several clients were
calling version 2 and 3 events including the desktop shell itself.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
In preparation for upcoming changes, we want to make sure that apps
written with the toy toolkit continue to operate properly if no XKB
keymap is received. If there's no XKB keymap, then we shouldn't
try to figure out keyboard modifier states (since we probably don't
even have equivalents of PC-style modifiers).
Reviewed-by: Singh, Satyeshwar <satyeshwar.singh@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
AC_USE_SYSTEM_EXTENSIONS enables _XOPEN_SOURCE, _GNU_SOURCE and similar
macros to expose the largest extent of functionality supported by the
underlying system. This is required since these macros are often
limiting rather than merely additive, e.g. _XOPEN_SOURCE will actually
on some systems hide declarations which are not part of the X/Open spec.
Since this goes into config.h rather than the command line, ensure all
source is consistently including config.h before anything else,
including system libraries. This doesn't need to be guarded by a
HAVE_CONFIG_H ifdef, which was only ever a hangover from the X.Org
modular transition.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
[pq: rebased and converted more files]
A wayland compositor doesn't provide a mechanism for buffer sharing between
clients. Under X, one client can render to a Pixmap and another can use it
as a source in a subsequent drawing operations. Wayland doesn't have a
mechanims to share Pixmaps or textures between clients like that, but it's
possible for one client to act as a nested compositor to another client.
This less work than it sounds, since the nested compositor won't have to
provide input devices or even any kind of shell extension. The nested
compositor and its client can be very tightly coupled and have very specific
expectations of what the other process should provide.
In this example, nested.c is a toytoolkit application that uses cairo-gl
for rendering and forks and execs nested-client.c. As it execs the client,
it passes it one end of a socketpair that will be the clients connection
to the nested compositor. The nested compositor doesn't even create a
listening socket.
The client is a minimal GLES2 application, which just renders a spinning
triangle in its frame callback.
Whether or not a shm pool is used for resizing is now configurable at
build time (--disable-resize-optimization).
[pq: removed an unnecessary hunk from the patch]
