This patch adds a new command line option which can be
used to tell headless backend not to create any
virtual outputs.
This will be used for output hotplug emulation, where
weston will start with no outputs available, and the
virtual output will be created at runtime.
v2:
- Use bool instead of int for the indicator flag
- Move final newspace to a separate line in command
line options
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Write the command line to the log to aid debugging. It needs to be
copied before parsing, because parsing mutates argv.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This is the start of separating weston-the-compositor source files from
libweston source files.
This is moving all the files related to the 'weston' binary. Also the
CMS and systemd plugins are moved.
xwayland plugin is not moved, because it will be turned into a
libweston feature.
To avoid breaking the build, #includes for weston.h are fixed to use
compositor/weston.h. This serves as a reminder that such files may need
further attention: moving to the right directory, or maybe using the
proper -I flags instead.
v2: Move also screen-share.c, and add a note about weston-launch.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
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.
This is the other direction. The selection bridge will grab the X11
CLIPBOARD selection on behalf of the Wayland client when it sets the
Wayland selection. Right now only UTF-8 text is supported, but the
data types offered will be taken from the Wayland data source.
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>
fade_output() is strange in that it manufactures a wlsc_surface object
by hand, and then calls wlsc_surface_draw() on it.
Valgrind complained, that wlsc_surface_draw() accesses uninitialised
data: wlsc_surface::alpha. fade_output() forgets to set it.
Initialise surface.alpha in fade_output(). Specifically, set it to
compositor->current_alpha to deliberatly avoid the gluniform1f() call in
wlsc_surface_draw().
fade_output() binds a different GL shader program than
wlsc_surface_draw() expects. This program does not have a uniform called
"alpha", and the uniform location given in glUniform1f() is not for
this program anyway. A hint of that is the runtime error:
Mesa: User error: GL_INVALID_OPERATION in glUniform(type mismatch)
Fixing this seems to get rid of half a thousand of Valgrind errors, and
of course the Mesa user error.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Not sure why we get these, but it happens for Alt-click to move a window
(metacity binding) and messes up the idle inhibit counter.
FocusOut event as a result of ungrabbing doesn't really make sense and
fortunately we can safely ignore them.
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>
I caught this when an evdev device fd was trying to trigger the main event
loop, which was already free'd and causing an invalid read.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Was causing an invalid read when the output is in fact destroyed. That's only
visible (segfault on my machine) on drm compositor because it's the only
backend trying to finish correct the compositor.
Signed-off-by: Tiago Vignatti <tiago.vignatti@intel.com>
Activate the toplevel, fullscrren and menu surfaces during mapping,
so that the launched applications can get the keyboard focus without
clicking on that window.
Move idle_time variable to struct wlsc_compositor, so that a shell
plugin can change it. Also store the original value from the command
line.
Add "duration" option to the desktop-shell screensaver config. This is
the time the screensaver will be visible, after idle timeout triggers
another time and blanks the screen.
Now you can have different delays to lock the screen, and switch off the
screen while a screensaver is running.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Read the same configuration file in the shell plugin (desktop-shell) as
the desktop-shell client does.
Add a new section "screensaver", where "path" defines the path of the
idle animation client to be executed. Not defining "path" disables the
animation.
Idle animations are not in use by default. It must be configured in
wayland-desktop-shell.ini or launched manually.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add WLSC_COMPOSITOR_IDLE state to the possible compositor internal
states, and fix the drm backend to restore the previous state instead of
forcing ACTIVE.
Normally, the compositor only uses the ACTIVE and SLEEPING states. The
IDLE state is another active state, reserved for the shell, when the
shell wants to have unlock() calls on activity, but the compositor cannot
be SLEEPING.
Use the IDLE state to fix exposing the unlock dialog while a screensaver
is animating. Without this fix, is it impossible to activate the unlock
dialog without waiting for a second idle timeout that really puts the
compositor into SLEEPING.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Reorder code in fade_frame() to that if shell->lock() calls
wlsc_compositor_wake(), the fade animation will run again.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Screensavers become visible the first time only after the compositor has
gone to sleep state. Therefore, to see screensaver in the start, wake up
the compositor. After a second idle timeout, the compositor will stay
sleeping.
We could also not apply this patch. It would mean the screensavers would
be visible only with the unlock dialog, and not become visible
automatically.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Implement the basics of screensaver surface management. Exec'ing and
killing the screensaver client is punted for later.
When a surface registered as a screensaver is mapped, it stays hidden
if the screen is not locked, or it is added to the compositor visible
surfaces list if the screen is locked.
The map() is restructured to set initial position first, and stacking
next. This allows SHELL_SURFACE_SCREENSAVER share positioning with
SHELL_SURFACE_FULLSCREEN, while show_screensaver() does its own
wlsc_surface_configure() call.
Also fix centering to the given fullscreen output, not the first output.
Another bug fix: previously configure() would call
wlsc_surface_configure() unconditionally, which assigns an output to
the surface. While the compositor is locked, if an application resizes
its window, we hit configure() and assign an output while the surface is
not in compositor->surface_list. This leads to invalid memory access on
the next call to wlsc_surface_damage_below(). Fix this by not calling
wlsc_surface_configure() for surfaces that are not visible.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
So far nothing prevented a client for registering a surface as one type
and then as another type. With some special types, this would lead to
corrupted wl_lists.
Add a function, that either resets the surface type or posts an error to
the client. In case of an error, the set type operation must be aborted.
Change the type name SHELL_SURFACE_NORMAL to SHELL_SURFACE_NONE, as
there is nothing normal in the "none" type which just means uninitialised.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add the screensaver interface to the desktop-shell protocol file. Also
add stubs for it in the compositor, and make wscreensaver to bind to the
screensaver interface. Wscreensaver gets a new option --demo to retain
the current behaviour as a regular wayland client.
When a screensaver application starts, it should bind to the screensaver
interface, enumerate all outputs, create a surface per output, and
register those surfaces via screensaver::set_surface request. Then it
continues with the usual animation loop, waiting for frame events. The
compositor will decide, when the given screensaver surfaces are
displayed. A screensaver application should respond to outputs coming
and going away by creating and destroying surfaces.
The compositor is supposed to activate a screensaver by exec'ing it, and
stop the screensaver by killing the client process. Only one client may
be bound to the screensaver interface at a time. If there already is a
client, the compositor could either kill it first, or not exec a new
one.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
