No need to add protocol/, as it's already handled by an explicit
compiler include path.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Dima Ryazanov <dima@gmail.com>
Add support for basic text file loading, to facilitate more expansive
testing of its UTF-8 text editing support.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Since 894b3rcc634 weston-terminal will crash on first keystroke if you
fail to create an xkb compose state. This can happen if you don't have
a Compose file.
Instead, now we just return uncomposed symbols.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
These variables will be much more useful in the following commit.
The indentation is off to avoid future diff noise.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Do a minimalistic teardown at program exist.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
... over a direct eglDestroySurface call. Provides symmetry in the
create/destroy paths.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
... over a direct eglDestroySurface call. Provides symmetry in the
create/destroy paths.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Functionally identical to the EXT version of the extension.
v2: s/foo/swap_damage_ext_to_entrypoint/ (Eric, Daniel)
v3: do the above sed for real (Frank)
[daniels: Fixed signed vs. unsigned warning.]
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com> (v1)
Reviewed-by: Daniel Stone <daniels@collabora.com>
In Fedora, bash is configured to display a desktop notification when a command
finishes (and the terminal is not focused). weston-terminal complains about it;
let's silence it.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Acked-by: Daniel Stone <daniels@collabora.com>
It's currently unused, and there's actually no way to use it correctly.
The caller cannot free the menu that was created:
- the function only returns the window, not the menu
- there's no public API to destroy a menu object
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
clients/terminal.c: In function 'redraw_handler':
clients/terminal.c:213:28: warning: 'machine.unicode' may be used
uninitialized in this function [-Wmaybe-uninitialized]
struct utf8_state_machine machine;
^~~~~~~
clients/terminal.c: In function 'handle_char':
clients/terminal.c:213:28: warning: 'machine.unicode' may be used
uninitialized in this function [-Wmaybe-uninitialized]
Warning produced by GCC 5.3 and 6.1, with -O3.
'I found it weird that the compiler wouldn’t see that, so I re-checked
the code.
I think with -O3, this specific "for" is compile-time unlooped, and
utf8_next_char inlined. And there is *one* path that can keep
machine.state to utf8state_start, thus triggering the warning.
Without -O3, the function is globally tagged as “changing unicode”, so
no warning is produced.
[...]
Side note: I picked 0 as the default value, but maybe in this case
0xfffd would be better?'
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Emil Velikov <emil.l.velikov@gmail.com>
If only the source of a viewport is set, the width and height must
be integer or the protocol mandates that the compositor generate an
error. This is because using only the source is a crop, and the
width and height become the surface size - all surface sizes must
be integer.
Weston was fixed to generate this error in bb32ccc0, however the
test app continued to use fractional co-ordinates when run as
weston-scaler -s (which only sets the viewport source)
This leaves fractional width/height for the other cases, but uses
integer for the crop-only mode. The descriptions in the help text
are still accurate with this change, but weston-scaler -s no longer
exits with an error.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
According to the xdg-shell v6 protocol a positioner object is only
complete if both the size and its anchor rectangle are set. Ensure the
weston clients do this and let weston be more strict on checking if a
client has done so.
This also fixes weston-terminal popups not showing up on gnome-shell
3.22.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Debian Jessie's version of libxkbcommon is too old for compose support,
so rather than force people to upgrade, let's make it conditional.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Díaz <daniel.diaz@linaro.org>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Except for weston-info, client source files are not prefixed "weston-".
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jan Arne Petersen <janarne@gmail.com>
XKB_KEYMAP_COMPILE_NO_FLAGS and XKB_CONTEXT_NO_FLAGS are both defined as
0 so no functional change here, just improved code clarity.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jan Arne Petersen <janarne@gmail.com>
This adds single-symbol compose support using libxkbcommon's compose
functionality. E.g., assuming you have the right alt key defined as
your compose key, typing <RAlt>+i+' will produce í, and <RAlt>+y+= will
produce ¥. This makes compose key work for weston-editor,
weston-terminal, weston-eventdemo, and any other clients that use
Weston's window.* routines for accepting and managing keyboard input.
Compose sequences are loaded from the system's standard tables. As
well, libxkbcommon will transparently load custom sequences from the
user's ~/.XCompose file.
Note that due to limitations in toytoolkit's key handler interface, only
compose sequences resulting in single symbols are supported. While
libxkbcommon supports multi-symbol compose strings, support for passing
text buffers to Weston clients is left as future work.
This largely obviates the need for the weston-simple-im input method
client, which had provided a very limited compose functionality that was
only available in clients implementing the zwp_input_method protocol,
and with no mechanism to load system or user-specified compose keys.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=53648
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
This patch fixes a compiler warning when building with
clang, since it doesn't support gnu_printf attribute.
v2:
- Switch to WL_PRINTF per suggestion from Eric Engestrom.
v3:
- Explicitly include wayland-util.h
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
weston-terminal intermittently crashes on startup. This occurs because
some parameters in the weston_terminal structure such as data_pitch,
don't get set to non-zero until the resize_handler() callback gets
triggered. That callback makes a call to terminal_resize_cells(), to
calculate the proper values for these parameters.
On occasion, the resize handler call is slow to resolve, and the program
proceeds to start processing characters for the terminal window. With
the parameters defaulting to zero, certain calculations come out wrong,
leading the program to attempt to scroll the buffer when it shouldn't,
and thus follows the crash.
Instead, force the call to terminal_resize_cells() during the init, with
some dummy defaults, to ensure the parameters are always non-zero.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97539
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Derive client from simple-shm and hook up the API defined in
wayland-protocols to allow client screensaver inhibition requests.
v5:
+ Add simple-idle client demo
+ Add command line options to delay creation/destruction of inhibitor
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
We're leaking the fd when sending cut'n'paste. Failure to close can also
makes the other end unhappy because it doesn't know the paste is finished.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Invert the Y_INVERT flag for the EGL import fo dmabufs. This fixes
weston-simple-dmabuf-intel to show the same image on both GL-composited
and with direct scanout on a hardware plane. Before, the image would
y-flip when switching between these two cases. Now the orientation also
matches the color values written in simple-dmabuf-intel.c.
The GL-renderer uses the OpenGL convention of texture coordinates, where
the origin is at the bottom-left of an image. This can be observed in
texture_region() where the texcoords are inverted if y_invert is false,
since the surface coordinates have origin at top-left. Both wl_shm and
dmabuf buffers have origin at the top-left.
When wl_shm buffer is imported with glTexImage2D, it gets inverted
because glTexImage2D is defined to read in the bottom row first. The shm
data is top row first. This incidentally also means, that buffer pixel
0,0 ends up at texture coordinates 0,0. This is now inverted compared to
the GL coordinate convention, and therefore gl_renderer_attach_shm()
sets y_inverted to true. This causes texture_region() to NOT invert the
texcoords. Wayland surface coordinates have origin at top-left, hence
the double-inversion.
Dmabuf buffers also have the origin at top-left. However, they are
imported via EGL to GL, where they should get the GL oriented
coordinates but they do not. It is as if pixel 0,0 ends up at texcoords
0,0 - the same thing as with wl_shm buffers. Therefore we need to invert
the invert flag.
Too bad EGL_EXT_image_dma_buf_import does not seem to specify the image
orientation. The GL spec implied result seems to conflict with the
reality in Mesa 11.2.2.
I asked about this in the Mesa developer mailing list. The question with
no answers:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
and the thread I hijacked to get some answers:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120733.html
which culminated to the conclusion:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120955.html
that supports this patch.
simple-dmabuf-v4l is equally fixed to not add Y_INVERT. There is no
rational reason to have it, and removing is necessary together with the
GL-renderer change to keep the image the right way up. This has been
tested with VIVID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Add very short explanation on how to set up Vivid driver, when you don't
have suitable V4L2 device to use.
Using the XR24 (DRM_FORMAT_XRGB8888) format practically guarantees that
you can test direct scanout on a hardware overlay, too. At least on PC
hardware that has overlays. Tested to work on Intel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Previously weston_config_section_get_uint was serving dual purpose for
parsing both unsigned decimal integer values (ids, counts, seconds,
etc.) and hexadecimal values (colors), by relying on strtoul's
auto-detection mechanism.
However, this usage is unable to catch certain kinds of error
conditions, such as specifying a negative number where an unsigned
should be used. And for colors in particular, it would misparse hex
values if the leading 0x was omitted. E.g. "background-color=99999999"
would render a near-black background (effectively 0x05f5e0ff) instead of
medium grey, and "background-color=ffffffff" would be treated as an
error rather than white. "background-color=0x01234567",
"background-color=01234567", and "background-color=1234567" each
resulted in the value being parsed as hexadecimal, octal, and decimal
respectively, resulting in colors 0x01234567, 0x00053977, and 0x0012d687
being displayed.
This new routine forces hexadecimal to be used in all cases when parsing
color values, so "0x01234567" and "01234567" result in the same color
value, "99999999" is grey, and "ffffffff" is white. It also requires
exactly 8 or 10 digits (other lengths likely indicate typos), or the
value "0" (black).
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
In order to test warping when pointer confinemen region changes, add
key binding to the maximized state without using the mouse.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
By passing --complex-confine-region confine will draw an area looking
like a strange H in half transparent gray. This region will act as the
confine region when pointer confinement is activated (by right clicking).
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
We can use this to test more complex confine regions.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Clear the white lines that is drawn by pointer motions. It makes it
easier to debug pointer movements as one won't need to restart confine
just to get a clean plate.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Use pointer confinement to make the line drawing not go outside the
drawing area. It is toggled with the letf pointer button.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The new confine client will be used to demonstrate pointer confinement.
It is so far identical to clickdot except that it doesn't respond to
clicks.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Acked-by: Daniel Stone <daniels@collabora.com>
