We dont want to receive hotplug events while being inactive.
When getting back active we enumerate all devices and would end up
with two sources for one device that may be hotplugged in the mean time.
weston-launch starts weston and provides mechanism
for weston to set/drop drm master, open a tty,
and read input devices without being root.
Execution is allowed for local-active sessions
or users in the group weston-launch.
Just like device_added, now the routines to close the compositor and vt switch
leave are using the same code to remove a device.
This patch also closes properly a mtdev device, bug spotted by Christopher
Michael.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
When the compositor is in a repaint cycle, input is processed only once
per frame. However, a call to evdev_input_device_data() would handle at
most 8 events at time. When there was more than 8 events pending for a
given frame, input lag would occur. This was most visible with multi
touch input.
This patch changes the evdev_input_device_data() so that it will handle
all the events available in the fd. In order to do that, the fd is put
in non-blocking mode, so that it is possible to loop on read and stop
on EAGAIN instead of blocking.
mtdev library translates all multitouch based devices to the slotted evdev
protocol. It provides an uniform interface for Weston, which eases mt
implementation when dealing with a big variety of devices.
Weston on drm now directly depends on such library.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This reverts commit fc6ccb868fa735ee9c6592806f381aa1262bf0b2.
We still need root permissions for drmDrop/SetMaster. Without
integration with ConsoleKit or systemd we also don't have access
to /dev/dri/cardX in the case where we open a new VT.
==30224== Conditional jump or move depends on uninitialised value(s)
==30224== at 0x40EE3A0: evdev_flush_motion (evdev.c:284)
==30224== by 0x40EE6DC: evdev_input_device_data (evdev.c:352)
==30224== by 0x4034710: wl_event_source_fd_dispatch (event-loop.c:76)
==30224== by 0x4035171: wl_event_loop_dispatch (event-loop.c:462)
==30224== by 0x4032F76: wl_display_run (wayland-server.c:785)
==30224== by 0x8050972: main (compositor.c:2183)
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
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.
