Usually there should be at least one input device, when Weston starts
up, or is reactivated by a VT switch. Add a nice warning, in case there
are no input devices.
This is to give a clue to users who happen to try Weston on DRM, and
do not get any response.
Add also a message to another failure case, that may lead to missing
input devices.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This rename addresses a few problems around the split between core
Wayland and the wayland-demos repository.
1) Initially, we had one big repository with protocol code, sample
compositor and sample clients. We split that repository to make it
possible to implement the protocol without pulling in the sample/demo
code. At this point, the compositor is more than just a "demo" and
wayland-demos doesn't send the right message. The sample compositor
is a useful, self-contained project in it's own right, and we want to
move away from the "demos" label.
2) Another problem is that the wayland-demos compositor is often
called "the wayland compsitor", but it's really just one possible
compositor. Existing X11 compositors are expected to add Wayland
support and then gradually phase out/modularize the X11 support, for
example. Conversely, it's hard to talk about the wayland-demos
compositor specifically as opposed to, eg, the wayland protocol or a
wayland compositor in general.
We are also renaming the repo to weston, and the compositor
subdirectory to src/, to emphasize that the main "output" is the
compositor.
We need to store all touchpoint positions so that if we just get an
ABS_MT_POSITION_X or Y event, we can pull the other coordinate from the
cache. And we need this across invocations of evdev_input_device_data(),
so the accumulator approach doesn't work.
Instead, we go back to the approach of storing all this state in the
evdev device struct and we might as well just move the rel and abs state
there too.
This adds ABS_MT_* support for direct touch devices and notifies
the compositor. The compositor has a stub for now.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Besides the new header file, there's also a change in the main evdev creation
procedure for a more suggestive name (evdev_input_add_devices ->
evdev_input_create). There's no real functional changes in this commit.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
when a motion is being performed on ts device, only one axis can be sent
through the evdev bytestream whereas the other could be omitted. For instance:
-------------- SYN_REPORT ------------
type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 22208
type 3 (EV_ABS), code 58 (ABS_MT_PRESSURE), value 631
type 3 (EV_ABS), code 0 (ABS_X), value 22208
-------------- SYN_REPORT ------------
on such case we'd have to send the compositor the old value of Y. Commit
f547bd36 introduced this bug cause it was sending zeroed coordinate and not
the old one.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
We'll want to enhance later the driver regarding the tool being used, but for
now just remove unused bits.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Very likely that 2.4 kernels won't be used with Wayland compositor so the
check for signal value is pretty much useless.
It's okay to change e->value inside evdev_process_absolute_motion_touchpad
given it's not used later on, and I also rather not touch this snip because it
will be changed when multi-touch support arrives.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
This isn't going to change over time, so just tracking it in the
evdev device is a little easier. Also, we need to adjust for the
output position when transforming the device events to screen space.
We may want to adjust the protocol later for clients that care for
these devices only, generating a special event.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
The wayland-system-compositor is the top-level compositor. X sessions
or nested Wayland sessions will run as clients of the system compositor.
The system compositor is licensed under the GPL.
Instead of having the input driver push the events into the core server,
only to have the server call back out to the compositor hooks, the driver now
just calls the compositor directly. The input drivers are always dependent on
the type of compositor anyway so there was no point in passing the events
through the server. Now the server is only involved when it's time to actually
send the events to the clients.
