There were some reset calls missing, which resulted in wrong preedit
state on input method side.
Signed-off-by: Jan Arne Petersen <jpetersen@openismus.com>
We used to rely on an ugly hack where the xwayland server would always
report RGB X windows as having ARGB pixels, so that texturing from these
would also sample the undefined alpha. We also relied on Xrender rendering
to RGB X windows to write the alpha channel correctly, so that when we
texture from the RGB X window as an ARGB surface we end up getting the
alpha written by Xrender.
That was obviously all broken. We can instead reparent client windows into
ARGB frame windows. That way we can render the decorations using a
ARGB render pictformat and sample back those alpha values in a well-defined
way. We can also unbreak xwayland and let it report RGB pixel format for
RGB windows. We still need the opaque region or the RGB-only client window
but that's OK.
in drm_fb_create_dumb, the return value of the drmIoctl function call
to map the dumb buffer was never checked, thus the following "if
(ret)" check was invalid as it was checking the previous return value
from the above drmModeAddFB call.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
wl_egl_window_destory() destroys the window handle that
dri2_destroy_surface() later uses when eglTerminate() is called.
Reordering the tear down order prevents such case from occuring.
Fixes a segfault. Steps to reproduce:
* start weston with the x11 backend
* open a terminal
* click on the icon in the top left corner, choose close
* close the x11 window containing weston
The keycodes received by the FreeRDP server aren't evdev keycodes.
This patch adds the correct convertion to evdev keycodes. After the
patch all keys that are marked as extended in RDP packets become
functionnal (that's the case for the windows key).
Please note that this patch rely on some corrections that have been
pushed on the FreeRDP github tonight.
Most backends relies on gettimeofday(2) for output repaint timestamps
but this is not a requirement. Before this patch repaints coming from
idle_repaint() always used gettimeofday(2) for timestamps. For backends
not using that time source this could cause large jumps between
timestamps.
To fix this, timestamps needs to always come from the backend. This
means that the backend needs to always be responsible of starting the
repaint loop in case that the repaint cannot start immediately.
The drm backend implementation is from the patch by Ander Conselvan de
Oliveira found here:
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This API call handles setting the current surface on the wl_pointer and also
maintaining a destroy notification to monitor that surface for destruction.
This is part of the fix for: https://bugzilla.gnome.org/show_bug.cgi?id=696946
This patch is the 6th version of the FreeRDP based compositor.
Changes from last version:
* use pixman_image_get_stride() when appropriate
* always realloc
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
This state is used when the user switches the vt. It turns of rendering
and frame events, but doesn't set the DPMS state to off.
As a part of this change, also turn off the idle timer when entering
the SLEEPING or OFFSCREEN states, which fixes
https://bugs.freedesktop.org/show_bug.cgi?id=61910 (rpi backend
untested).
Automake (1.12 here) parallel-tests installs a test-driver file, another
file to add to .gitignore.
While at it, remove the duplicate cscope.out entry and add TAGS (the
result of automake's "make tag")
Otherwise, it means the X11 compositor depends on another library to
pull xcb-shm (cairo?), which is not always the case. Here I end up with:
[01:54:38.970] Failed to load module:
$prefix/lib/weston/x11-backend.so: undefined symbol: xcb_shm_id
This ensures the popup_grab.initial_up field isn't reset to 0
if the popup was not opened because of a mouse press but because
of moving the mouse with a popup already open. Not doing so will
make the first click outside the client area go ignored.
This patch implements a popup stack. When the first popup is opened
the grab is started, and it is added to a list. Further popups will
be added to this list but the grab won't change. When a popup is
closed it is removed from the list and, if it is now empty, the grab
is ended.
A click outside the client area will send the popup_done event to
all the popups in the list, and the grab will end.