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.
When we destroy a surface, we damage the surface below so that the area
exposed by the disappearing surface will be repainted. However, if that
surface also is destroyed, the damage information is lost and we fail to
repaint that area.
This commit introduces weston_surface_flush_damage(), which flushes the
surface damage the the surface below when a surface is destroyed. When
multiple surfaces are destroyed at the same time, the damage now accumulates
and sinks down through the surface stack as it should.
If we don't cancel the repaint, we end up pointlessly redrawing the output.
What's worse is that pageflipping to the new buffer eventually fails and
we miss the finish_frame callback, leaving the compositor stuck when we
re-enter the vt.
When we later upload the cursor image with glTexImage2D(), that will unbind
the image just fine. No need for a NULL upload. Except that that doesn't
currently happen with mesa drivers, but the NULL upload is redundant either
way.
Weston initialises to faded-out state, which means all outputs are just
black, even if they render fine.
Previously the fade-in was triggered probably by some random input
event, since Weston was not guaranteed to wake up. Especially with the
drm backend, and the usual problem of not having permissions to input
devices, Weston would not fade in at all and appear broken.
Force Weston to fade in right after initialisation. This show that at
least rendering works, if it does not respond to any input.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
This collided with the big weston rename, but git did a good job of fixing
most cases.
Conflicts:
compositor/compositor.h
src/compositor-x11.c
src/compositor.c
src/screenshooter.c
src/util.c
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.
