Compositor core does not do anything with udev, so the header is not
needed there. Move the #include into evdev.h, from where it gets used by
compositor-drm.c, too.
Also fix the fallout:
tty.c: In function 'tty_create':
tty.c:143:2: warning: implicit declaration of function 'fstat'
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
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.
This reverts commit fc6ccb868f.
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.
This is typically when launcing from a pty such as an X (or Wayland)
terminal or from an ssh session. Opening a new vt typically requires root
priviledges, so weston must be setuid root or laucnhed as root for this
to work.
We can only set up once we've acquired the VT and we shouldn't release the
VT until we've cleaned up. Before we would release the VT first, and then
race to drop drm master as X tried to get drm master. Which would kill X.
Part of the point of KD_GRAPHICS mode is that the kernel doesn't try
to restore the VT contents when we switch bach, but leaves that
to the user mode process. This avoids ugly flicker of text mode contents
before the compositor takes over.
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.
(!x < 0) is always false and doesn't make sense here. Looks like a typo so
remove the negation.
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
This lets the compositor place the pointer sprite correctly when it receives
pointer focus and allows it to send pointer focus to any client that might
receive pointer focus as the compositor receives it.
Martin Minarik
Pekka Paalanen
Kristian Høgsberg
Benjamin Franzke
Jonas Ådahl
David Herrmann
Tiago Vignatti
Tim Wiederhake