This makes drm_fb_get_from_bo() use drmModeAddFB2() if possible so that
drm_output_prepare_overlay_surface() can use this instead of keeping
track of the fbs and buffers itself.
Let the compositor generic code decide what to do when the buffer goes
away. We still have a valid reference do the bo, so we can still show
the client contents until something else triggers a repaint.
If the sprite is disabled and we're not enabling it on the next frame,
nothing is done in the vblank handler, so there's no need to ask for a
vblank event.
The old implementation didn't work because we set the minimum and maximum
sizes so that the WM can't resize us. That makes the fullscreen protocol
not work. Additionally we were requesting fullscreen after mapping, which
requires the more complicated (and potentially flickery) client message
approach.
Now we just set the _NET_WM_STATE before mapping and avoid setting
the size hints in case of fullscreen. That's all good, but the problem
is that we now have to wait for configure notify before we know
what size our output will be. For now we just block and pull events from
X until we get the size.
Ideally we would treat the map as an output hotplug event and just add the
output at that point, but we can't start up with no outputs present.
That may be worth fixing, but for now, the block-on-map is fine.
Dispmanx elements are like hardware overlays. Assign one weston_surface
to each overlay created, and the VideoCore will composite it on screen.
The maximum number of elements is configurable via the command line.
Specifying zero will disable the overlays (planes/elements) altogether,
and use only GLESv2 compositing.
You need an up-to-date Raspberry Pi firmware for:
- vc_dispmanx_resource_create(), that will also take stride. Otherwise
surfaces ending up in elements may show up as corrupted.
- off-line compositing support. The on-line compositing of elements
cannot handle too many elements. Look for the comments around
DEFAULT_MAX_PLANES in the code.
Elements must be double-buffered to avoid tearing. Therefore two buffers
(Dispmanx resources) are allocated for each element. A command line
option is added to allow single-buffering instead to save memory, with
the risk of tearing.
The page flip timer is replaced with the Dispmanx update completion
callback. The callback is executed in a separate thread, therefore a
pipe is set up to integrate properly with Weston core.
If not disabled, usually all surfaces are assigned into planes, and
nothing is composited in GLESv2. Planes do not support surface
transformations though, so compositing will automatically switch the
necessary surfaces to GLESv2 compositing as needed. Switching between
GLESv2 and elements may cause transient visual glitches and jerks.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add a new backend for the Raspberry Pi.
This backend uses the DispmanX API to initialise the display, and create
an EGLSurface, so that GLESv2 rendering is shown on the "framebuffer".
No X server is involved. All compositing happens through GLESv2.
The created EGLSurface is specifically configured as buffer content
preserving, otherwise Weston wouuld show only the latest damage and
everything else was black. This may be sub-optimal, since we are not
alternating between two buffers, like the DRM backend is, and content
preserving may imply a fullscreen copy on each frame.
Page flips are not properly hooked up yet. The display update will
block, and we use a timer to call weston_output_finish_frame(), just
like the x11 backend does.
This backend handles the VT and tty just like the DRM backend does.
While VT switching works in theory, the display output seems to be
frozen while switched away from Weston. You can still switch back.
Seats and connectors cannot be explicitly specified, and multiple seats
are not expected.
Udev is used to find the input devices. Input devices are opened
directly, weston-launch is not supported at this time. You may need to
confirm that your pi user has access to input device nodes.
The Raspberry Pi backend is built by default. It can be build-tested
without the Raspberry Pi headers and libraries, because we provide stubs
in rpi-bcm-stubs.h, but such resulting binary is non-functional. If
using stubs, the backend is built but not installed.
VT and tty handling, and udev related code are pretty much copied from
the DRM backend, hence the copyrights. The rpi-bcm-stubs.h code is
copied from the headers on Raspberry Pi, including their copyright
notice, and modified.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
When a surface is on a non-primary plane (overlay), we do not need to
keep the GL texture up-to-date, since we are not using it. Avoid calling
glTex(Sub)Image2D in that case, and accumulate the texture damage
separately.
This is especially useful for backends, that can put wl_shm buffers into
overlays.
The empty damage check has to be moved from surface_accumulate_damage()
into gles2_renderer_flush_damage(), because it really needs to check the
accumulated damage, not only the current damage. Otherwise, if a surface
migrates from a plane to the primary plane, and does not have new
damage, the texture would not be updated even for accumulated damage.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Instead of hardcoding drm-backend.so as the default if environment
presents neither Wayland nor X11, have a ./configure option to change
it. It still defaults to drm-backend.so, if not given.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
Add the concept of debug key bindings, that are bindings that activate
debug features in the compositor. The bindings are added to a list in
the compositor, but the triggering them is left to the shell.
On the shell side, a global debug key binding is added. When the user
presses mod-shift-space, the shell will invoke the debug bindings based
on the next key press.
This also converts the debug shortcuts for repaint debugging, fan
repaint debugging and the hide overlays shortcut in compositor-drm to
use the new infrastructure.
Add a headless backend and a noop renderer, mainly for testing
purposes. Although no rendering is performed with this backend,
this allow some of the code paths inside Weston and shm clients
to be tested without any windowing system or any need for drm
access.
XKB provides keypad symbols in a separate namespace. We don't care
about the distinction, so map them to normal symbols before starting
processing.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Do not try to insert the input panel layer in the layer list when the
shell is locked in show_input_panels(). The layer will already be
insrted in resume_desktop() anyways.
https://bugs.freedesktop.org/show_bug.cgi?id=56543
Signed-off-by: Jan Arne Petersen <jpetersen@openismus.com>
The following sequence:
wl_surface::attach(s, b, 1, 2)
wl_surface::commit(s)
wl_surface::commit(s)
would actually result in the surface getting moved by (2,4) as the
pending attach delta wasn't reset on commit, only by another attach.
This only shows up on single-buffered surfaces.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Every single frame, we were calling the flush_damage handler in the
renderer. For GLES2 with subimage, this wasn't too bad as we'd never
call glTexSubImage2D, but without it, we'd upload the entire frame
through glTexImage2D every time.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Avoids a segfault whenever we get a key event, and try to set the
cursor, dereferencing a NULL input->pointer.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The break statement wasn't copy and pasted along with the rest of the code
causing menu item before it ("Move to workspace below") to fall through to
the fullscreen case.
In order to use XKB capabilities (as we do), the client must issue an
XkbUseExtension request:
http://www.x.org/releases/current/doc/kbproto/xkbproto.html#Initializing_the_X_Keyboard_Extension
The reason this succeeds currently is that XOpenDisplay from Xlib does
this for us. But it is better not to rely on that, but do it explicitly
in XCB with the rest of the XKB init sequence.
Signed-off-by: Ran Benita <ran234@gmail.com>
Where we don't look at the error details, pass NULL to the 'error'
argument and test using the reply return value instead.
Where we do need it, remember to free it.
Signed-off-by: Ran Benita <ran234@gmail.com>
Pressing ctrl-alt-o will cause the overlays to be hidden, but surfaces
will still be assigned to different planes. This helps with debugging
of repaint culling below surfaces in other planes.
Culling of the repaint of a surface behind an opaque surface on the
same plane was broken by commit 547149a9 [1]. The idea of that commit
is that the damage obscured by an overlay would remain on the primary
plane damage and be repainted when the overlay moved. However, in the
case the two surfaces are on the same plane, the opaque one is not
obscured, so it ends up being repainted.
This commit adds an opaque field to struct weston_plane, that is built
incrementally when accumulating damage. The opaque region of surfaces
on the same plane are removed from the plane's damage, restoring the
previous culling behavior. But since damage behind opaque region of
other planes is maintained, the bug solved in the mentioned commit is
not regressed.
https://bugs.freedesktop.org/show_bug.cgi?id=56537
In order to use xcb_request_check(), given a request without a reply,
you need to use the _checked() variant of the request function.
See xcb-requests(3).
Signed-off-by: Ran Benita <ran234@gmail.com>
We need to clamp or center on a per axis basis. If the window is wider
but the image is taller, we need to center horizontally but
clamp vertically. We can only do that if by combining the two
functions.
Clicking outside popups closes them except in case of a shell grab
(move, resize or rotate), in which case we move the parent window away
from under the popup. Instead, just end the popup in those cases.
https://bugs.freedesktop.org/show_bug.cgi?id=55674
Partial repaints have been broken since the introduction of the atomic
surface updates. The problem was that surface_commit would set the
geometry dirty flag unconditionally, causing transform updates on every
frame which would in turn cause weston_surface_damage_below() to damage
the whole surface area.
This patch changes this so that flag is only set if the pending buffer
has a different size, the location of the surface changed or the opaque
region changed.
Note that changing the opaque region will cause a full repaint of the
affected surface, because of the transform update.
https://bugs.freedesktop.org/show_bug.cgi?id=56538
The intended behavior is that a quick click (press and then release
within 500ms) just pops up the menu and doesn't select anything. Then
we can mouse around and and click to select an item. Alternatively, a
click and hold (ie press and release after 500ms) lets you press right
button, mouse down on the menu item you want and release to select it.
This is how menus work in most toolkits.
The handling in weston is fine, it's there to handle the case where
the button release happens outside any client window, since the client
doesn't get those events. If such a release happens late or we get a
second release outside the popup window we shut down the popup.
The problem is in toytoolkit, where we need to select the item if we
get a release within 500ms or if we get a second release. A second
release is the case where the first release came after 500ms and
didn't pop down the menu, and the second release event is from a click
on a menu item.
https://bugs.freedesktop.org/show_bug.cgi?id=52456
If clients don't set a cursor, they get whatever the last cursor was
before the pointer entered their window. That's a little confusing, so
set a pointer on enter to avoid that. The down-side is that simple EGL
isn't very simple anymore.
https://bugs.freedesktop.org/show_bug.cgi?id=52452
If we can find a boot_vga PCI GPU, we should prefer it over any other GPU
that is connected to the system. The boot_vga flag tells us that this GPU
is the primary system GPU.
This fixes problems on two-GPU-systems were the wrong GPU is used. It also
fixes systems were DisplayLink GPUs are available with lower IDs than PCI
GPUs (although, this seems unlikely).
Note that udev_enumerate guarantees that the entry-list is sorted. So for
systems that have platform-GPUs, these should almost always be reported
prior to hotpluggable (PCI, USB, ...) GPUs, as the kernel probes them
first.
https://bugs.freedesktop.org/show_bug.cgi?id=56237
Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>
Dima Ryazanov
Ander Conselvan de Oliveira
Kristian Høgsberg
Pekka Paalanen
Jan Arne Petersen
Daniel Stone
Ran Benita
Scott Moreau
David Herrmann