weston

Neil Roberts daf7d4774b evdev: Only track one pending event Instead of having a mask of pending events there is now an enum with a single value to represent the one pending event. The event gets flushed explicitly as part of the handling code for each event type rather than in the outer event reading loop. The pending event is used so that we can combine multiple motion events into one and to make sure that we have recieved the latest position before sending a touch up or down event. This should fix the following problems with the old approach: • If you release a finger and press it down again quickly you could get the up and down events in the same batch. However the pending events were always processed in the order down then up so it would end up notifying two down events and then an up. The pending event is now always flushed when there is a new up or down event so they will always be in the right order. • When it got a slot event it would immediately change the slot number and then set the pending event. Then when it flushed the events it would use the new slot number to flush the old pending event so the events could have the wrong finger. The pending event is now immediately flushed when a slot event is received so it will have the right finger. • If you get more than 32 events in one read then it was resetting the pending events before processing the next batch in evdev_process_events. If four fingers were pressed down at once then it ended up with more than 32 events and the sync message would be in the second batch. The pending flag for the last finger was getting cleared so it never got emitted. In this patch the pending event is no longer reset after reading nor is it explicitly flushed. Instead it is flushed when we receive a EV_SYN event or a different pending event needs to replace it. The touchpad handling code was trying to use the pending event mechanism to notify the relative motion events. I'm not sure why it was doing this because it looks the event would effectively get emitted as soon as the touchpad_process function is finished anyway and it wasn't accumulating the values. Instead I've just changed it to emit the event directly. https://bugs.freedesktop.org/show_bug.cgi?id=67563		11 years ago
clients	clients: Include and link against math lib for new multi-resource	11 years ago
data	window.c: frame_button: Maximize, minimize, close, icon buttons in window frame	13 years ago
man	add [xwayland] path weston.ini option	11 years ago
protocol	protocol: Add missing xml files to EXTRA_DIST	13 years ago
shared	compositor: Log the full path of the config file we're using	11 years ago
src	evdev: Only track one pending event	11 years ago
tests	config-parser: Make weston_config_parse() tkae a file name	11 years ago
wcap	Add more missing config.h #includes	11 years ago
.gitignore	Update .gitignore	11 years ago
COPYING	Add COPYING	13 years ago
Makefile.am	autotools: Don't use wayland-scanner.m4	11 years ago
README	Flesh out README a bit, link to building instructions	13 years ago
autogen.sh	Update autotools configuration	14 years ago
configure.ac	configure.ac: Update version to 1.2.91	11 years ago
notes.txt	Add informal notes file	12 years ago
wayland-scanner.mk	autotools: Don't use wayland-scanner.m4	11 years ago
weston.ini	weston.ini: update path for the flower client	11 years ago

README

Weston

Weston is the reference implementation of a Wayland compositor, and a
useful compositor in its own right.  Weston has various backends that
lets it run on Linux kernel modesetting and evdev input as well as
under X11.  Weston ships with a few example clients, from simple
clients that demonstrate certain aspects of the protocol to more
complete clients and a simplistic toolkit.  There is also a quite
capable terminal emulator (weston-terminal) and an toy/example desktop
shell.  Finally, weston also provides integration with the Xorg server
and can pull X clients into the Wayland desktop and act as a X window
manager.

Refer to http://wayland.freedesktop.org/building.html for buiding
weston and its dependencies.