When the focus changes, wl_keyboard_set_focus (and, as an added bonus,
wl_pointer_set_focus) will now send wl_keyboard::modifier events for us
if we store the modifier state in the right place, so we don't have to
worry about that anymore.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
If the cursor didn't change since last time we had pointer focus we just
wouldn't change it. But whoever had pointer focus in the mean time could
have changed it, so make sure we always set the cursor after pointer enter.
When the icon provided in weston.ini is not available, it will report a segfault error.
Check the icon at first.
backtrace:
*INT_cairo_surface_status (surface=0x0) at cairo-surface.c:259
259 {
(gdb) bt
#0 *INT_cairo_surface_status (surface=0x0) at cairo-surface.c:259
#1 0x0804baca in tablet_shell_add_launcher (data=0xbfb800ec)
at tablet-shell.c:404
#2 launcher_section_done (data=0xbfb800ec) at tablet-shell.c:434
#3 0x08051121 in parse_config_file (
path=0x8b96c10 "/root/.config/weston.ini", sections=0x8053c80,
num_sections=2, data=0xbfb800ec) at config-parser.c:113
#4 0x0804c0f9 in main (argc=1, argv=0xbfb801d4) at tablet-shell.c:480
Signed-off-by: Juan Zhao <juan.j.zhao@linux.intel.com>
It seems we used to rely on the repaint scheduled by the cursor motion.
But if there's no cursor, there's no cursor motion, so we need to schedule
our own repaint.
Print an user friendly error mesage when
the variable is not a valid directory.
krh: Edited to make message a litle more precise and added a check to
verify XDG_RUNTIME_DIR ownership and access mode.
Since we now batch up damage and only handle it at repaint time, we need
to apply it in case a buffer is destroyed so we don't lose it.
Ander found the problem, but we need to fix it in the compositor so we
don't change the behavior of the compositor.
weston_surface_update_transform() is typically called as part of the
repaint cycle so don't schedule a repaint here. There are still a couple
of places where we call weston_surface_update_transform() manually, but
they don't rely on the repaint being scheduled.
We need to initialize prev when we handle the initial pixel in a
rectangle, or we may detect the following pixel as identical or different
when it's not. This causes the top-left pixel in a rectangle to
occasionally be wrong leaving a trail of "dirty pixels" in the capture.
This is the point where we have just finished rendering the new scene
but before we swap it to the front buffer. At this point, the
output->previous_damage region exactly corresponds to what was just
renders, as compared to previous frame.
We start tracking which hardware plane a surface is displayed on, which
lets us avoid generating damage when a hardware overlay/cursor is moved
around.
Daniel Stone
Kristian Høgsberg
Jan Arne Petersen
Juan Zhao
Martin Minarik
Ander Conselvan de Oliveira
Alexander Preisinger