Allow proper handling of output->pipe > 1 to support
triple-head graphics cards etc. by using the "high-crtc"
support introduced in Linux 2.6.39 and libdrm 2.4.25
around May 2011.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Initialize output->native_mode with the initially chosen
mode for an output, so weston_output_mode_switch_to_native()
has something to work with and can switch back from temporary
selected modes to the outputs native mode. Before, this was a
no-op.
This allows an output to switch back to its default mode if
a former toplevel fullscreen shell surface created via method
WL_SHELL_SURFACE_FULLSCREEN_METHOD_DRIVER gets destroyed, or
it gets demoted to non-fullscreen, or if modesetting on the
output failed for some reason.
v2: Modified and split into a separate patch from original
patch "Allow restore_output_mode() to work properly.",
as suggested by Derek Foreman.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Derek Foreman <derekf@osg.samsung.com>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
The matching logic in choose_mode() compared refresh rate
of a drm_mode candidate mode expressed in Hz against the
requested refresh rate of the target weston_mode expressed
in milliHz, so the match always failed and the logic always
ended up the mode with the highest refresh rate for a given
resolution, instead of the one matching the requested rate.
Match proper fields to fix this.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
To help reduce code duplication and also 'kitchen-sink' includes
the ARRAY_LENGTH macro was moved to a stand-alone file and
referenced from the sources consuming it. Other macros will be
added in subsequent passes.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
With the recent universal plane and atomic modeset / nuclear pageflip
development in the kernel, cursor content updates on Intel are currently causing
an extra wait for vblank. This drops Weston's framerate to a fraction by
2 when cursor contents update. This combined with the damage tracking
bug in Weston which causes cursor content updates on every frame the
cursor moves makes using hw cursors really bad.
It is possible that the Intel DRM driver will get fixed and cursor
updates there revert to their old behaviour on the contemporary KMS API.
However, it is hardware dependant whether cursor updates can happen
immediately. Some other hardware, especially ARM-related, may not be
able to do immediate updates. Therefore it is better to just not even
try - we should rely only on the lowest common denominator behaviour
between hardware and drivers as there is no and will not be any way to
reliably detect it.
Note, that while having different drivers do different things (immediate
update vs. update that gets latched on the next vblank), we cannot
rearrange the contemporary KMS API calls such that it would always work
fine. Either some hardware would update the cursor too early, or other
hardware would update the cursor too late and perhaps cause the
framerate decimation.
Mark hardware cursors broken by default. This avoids using them, and
works around the immediate problem of framerate issues in Weston. This
follows the same reasoning why hardware overlay planes have been
disabled by default for a long time.
This disablement will be removed once the current code for hardware
planes and cursors is replaced with code using the atomic KMS API.
The Intel driver change that exposed this problem is
38f3ce3af5
which is first included in Linux 4.0-rc1.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: nerdopolis <bluescreen_avenger@verizon.net>
Cc: Daniel Stone <daniel@fooishbar.org>
Cc: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-By: David FORT <contact@hardening-consulting.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
If the GL implementation doesn't provide an XRGB visual we may still be
able to proceed with an ARGB one. Since we're not changing the scanout
buffer format, and our current rendering loop always results in saturated
alpha in the frame buffer, it should be Just Fine(tm) - and probably better
than just exiting.
This is a workaround for https://bugs.freedesktop.org/show_bug.cgi?id=89689
Reviewed-By: Bryce Harrington <bryce@osg.samsung.com>
Tested-By: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-By: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Currently we pass either a single format or no formats to the gl renderer
create and output_create functions. We extend this to any number of
formats so we can allow fallback formats if we don't get our first pick.
Reviewed-By: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-By: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
The compositor's output_created signal used to be sent in weston_output_init()
which the backend call before putting the output in the output_list.
This caused problems when creating a new view in a listener to that signal,
because weston_view_assign_output() doesn't yet know the new output exists.
To fix this add a new weston_composito_add_output() func which adds the
output in the list and later sends the signal, and make the backends call
that.
This means compositors don't need to call supports() manually and
create() will just return -1 in the failure case as before. This also
means we can deal with the case of eglGetProcAddress returning
non-NULL but not actually being available at runtime.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Create a new function weston_compositor_read_presentation_clock() to
wrap the clock_gettime() call for the Presentation clock.
Reading the presentation clock is never supposed to fail, but if it
does, this will notify about it. I have not seen it fail yet, though.
This prepares for new testing features in the future that might allow
controlling the presentation clock. Right now it is just a convenience
function for clock_gettime().
All presentation clock readers are converted to call this new function
except rpi-backend's rpi_flippipe_update_complete(), because it gets its
clock id via a thread-safe mechanism. There shouldn't be anything really
thread-unsafe in weston_compositor_read_presentation_clock() at the
moment, but might be in the future, and weston core is not expected to
need to be thread-safe.
This is based on the original patch by
Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Support for scissor not implemented yet on cursor overlay or for direct
scanout. Overlays OTOH use the boundingbox to compute their coordinates,
so that should probably work.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Tested-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-By: Derek Foreman <derekf@osg.samsung.com>
PRESENTATION_FEEDBACK_KIND_ZERO_COPY is a flag that needs to be set for
each surface separately. Some surfaces may be zero-copy (as defined by
Presentation feedback) while some are not.
A complication with Weston is that a surface may have multiple views on
screen. All copies (views) of the surface are required to be zero-copy
for the ZERO_COPY flag to be set.
Backends set per-view feedback flags during the assing_planes hook, and
then Weston core collects the flags from all views of a surface.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Change weston_output_finish_frame() signature so that backends are
required to set the flags, that will be reported on the Presentation
'presented' event. This is meant for output-wide feedback flags. Flags
that vary per wl_surface are subject for the following patch.
All start_repaint_loop functions use the special private flag
PRESENTATION_FEEDBACK_INVALID to mark, that this call of
weston_output_finish_frame() cannot trigger the 'presented' event. If it
does, we now hit an assert, and should then investigate why a fake update
triggered Presentation feedback.
DRM:
Page flip is always vsync'd, and always gets the completion timestamp
from the kernel which should correspond well to hardware. Completion is
triggered by the kernel/hardware.
Vblank handler is only used with the broken planes path, therefore do
not report VSYNC, because we cannot guarantee all the planes updated at
the same time. We cannot set the INVALID, because it would abort the
compositor if the broken planes path was ever used. This is a hack that
will get fixed with nuclear pageflip support in the future.
fbdev:
No vsync, update done by copy, no completion event from hardware, and
completion time is totally fake.
headless:
No real output to update.
RDP:
Guessing that maybe no vsync, fake time, and copy make sense (pixels
sent over network). Also no event that the pixels have been shown?
RPI:
Presumably Dispmanx updates are vsync'd. We get a completion event from
the driver, but need to read the clock ourselves, so the completion time
is somewhat unreliable. Zero-copy flag not implemented though it would
be theoretically possible with EGL clients (zero-copy is a per-surface
flag anyway, so in this patch).
Wayland:
No information how the host compositor is doing updates, so make a safe
guess without assuming vsync or hardware completion event. While we do
get some timestamp from the host compositor, it is not the completion
time. Would need to hook to the Presentation extension of the host
compositor to get more accurate flags.
X11:
No idea about vsync, completion event, or copying. Also the timestamp is
a fake.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Acked-by: Mario Kleiner <mario.kleiner.de@gmail.com>
When a function is named drm_output_FOO(), you'd expect it to take a
struct drm_output * as an argument. Convert
drm_output_prepare_scanout_view(), drm_output_prepare_overlay_view(),
drm_output_prepare_cursor_view() from weston_output to drm_output.
Additionally convert drm_sprite_crtc_supported() from weston_output to
drm_output.
This change makes drm_assign_planes() to operate on drm_output terms,
which makes further changes a tiny bit easier.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Logind sends us a notification whenever the Active attribute of our session
changes. However, due to the way compositor-drm.c relies on the master DRM
device to be synced with the session, we used to delay Active=true
handling until the DRM device was up, too. See:
commit aedc7732eb
Author: David Herrmann <dh.herrmann@gmail.com>
Date: Sat Nov 30 11:25:45 2013 +0100
logind: delay wakeup until DRM-device is resumed
However, the other compositor backends do not use DRM, so logind-util will
never get notified about any DRM device. Therefore, we have to forward the
Active=true change immediately.
This commit fixes logind-util to take sync_drm as argument. If it is true,
we do DRM-device synchronisation, otherwise we don't.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=86889
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Tested-by: nerdopolis <bluescreen_avenger@verizon.net>
Most of the backends do their own parsing of transform strings, so let's
put that all in the same place (compositor.c/h)
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The comments already call it bool, so let's just make it one
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add 'msc' field to weston_output to maintain the refresh counter, and
use it in presentation_feedback.presented.
Make compositor-drm update the per-output refresh counter with the
values reported by DRM. If the DRM reported value jumps backwards,
assume it wrapped around once.
Other backends do not update weston_output::msc, and there
presentation_feedback will always deliver refresh counter as zero.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v3 Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Add presentation clock setters that verify the given clock actually
works. Offer an automatic choice of a software fallback clock, when a
backend has to always use clock_gettime() to approximate the
presentation time.
The DRM backend already queried the DRM about the clock id, just let the
DRM backend set the presentation clock from that.
For all other backends which do not get a timestamp from the driver,
call the software clock setter to choose a suitable clock.
Report the chosen clock via presentation.clock_id event to clients.
In finish_frame(), upgrade the argument from uint32_t milliseconds to
struct timespec which can accurately hold the presentation clock values.
This will be needed when weston_output_finish_frame() starts to send out
presentation_feedback.presented events.
While at it, replace gettimeofday() calls with clock_gettime() using the
chosen presentation clock, so we manufacture presentation timestamps
from the presentation clock when the gfx drivers cannot give us a proper
timestamp.
Rpi patch is more verbose due to not having the compositor pointer
available in rpi_flippipe_update_complete(). Explicitly carry the clock
id with flippipe so it is available in the thread.
Changes in v4:
* rpi debug build fix
v4 Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v3 Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
weston_surface_update_transform() no longer exists, except in comments.
Fix that.
[Pekka Paalanen: don't lose the full comment in compositor-drm.c.]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Init cursor size to 64x64 if drmGetCap() fails.
Use Mesa GBM_BO_USE_CURSOR define (which removes 64x64 restriction)
Signed-off-by: Alvaro Fernando García <alvarofernandogarcia@gmail.com>
The error handling for the function that writes the encoded frame on
the disk was bogus, always assuming the buffer supplied to the encoder
was too small. That would cause a bigger buffer to be allocated and
another attempt to encode the frame was done. In the case of a failure
to write to disk (due to ENOSPC, for instance) that would cause an
endless loop.
Possibly-related-to: https://bugs.freedesktop.org/show_bug.cgi?id=69330
If the scale for the cursor surface doesn't match that of the output
then we shouldn't use the cursor overlay because otherwise it will be
drawn at the wrong size. This problem is particularly noticable with
multiple pointers because it randomly alternates between drawing one
cursor or the other at a larger size depending on which one gets put
in the cursor overlay.
Commit 58e15865 changed the parameters for udev_get_seat_by_name() to
receive a struct udev_input. However, when this gets called from
create_output_from_connector() during initialization, the input struct
is not yet initialized, leading to a crash. Previously, that function
would take only a pointer to the compositor.
This patch fixes the crash by initializing input before creating any
outputs.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=77503
It takes the stride in bytes, not pixels. The bug was hidden when using
va intel-driver 1.2.1 because it would ignore the stride from user and
set the surface state in a wrong way.
https://bugs.freedesktop.org/show_bug.cgi?id=77495
The CURSOR_PLANE capability indicates that the backend has a concept of a
cursor plane and can handle a cursor without compositing. This is currently
only advertised by the DRM backend.
The ARBITRARY_MODE flag specifies that the backend is capable of switching to
virtually any resolution. This is currently only advertised in the RDP
backend. While it's a bit buggy right now, it should be capable of this.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Queueing in the Presentation extension requires splitting the viewport
state into buffer state and surface state. To conveniently allow
assigning only one, the other, or both, reorganize the
weston_buffer_viewport structure.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
While disable by default, passing --enable-libinput-backend to
./configure switches the input backend in weston's drm, fbdev and rpi
compositing backends to use libinput instead of udev-seat.c, evdev.c and
friends.
When enabled, weston now also depends on libinput >= 0.1.0.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
The gbm-format configuration option can now be specified per-output as
well as in the core config section. If it is not specified it will
default to the format specified in the core section. The
EGL_MESA_configless_context extension is required for this to work. If
this extension is available it will create a context without an
EGLConfig and then it will potentially use a different EGLConfig for
each output.
The gl-renderer interface has been changed so that it takes the EGL
attributes and visual ID in the create_output function as well as in
the create function.
If we VT switch away between picking a cursor surface and actually doing
the pageflip in drm_output_repaint(), we never set output->cursor_view to
NULL. Then we unplug all the input devices and as the last pointer device
goes away we destroy the cursor surface. Then when we switch back, we
call drm_output_set_cursor() with an invalid surface and crashes.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73566
Use the STAMP_SPACE to make the output mode logging
a little nicer looking.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
The opaque region is in surface coordinates, which we compare to the
output region, which is in compositor coordinates. For non-primary
outputs, that means that the output region is not located at 0,0 but
something like 1920,0 instead. That means that the output region isn't
contained in the surface opaque region and then we decide we can't scan
out from it.
Instead, compare the surface opaque region to the output region
translated to 0,0.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=7348i5
This patch fixes an issue where Weston using the DRM backend, cannot start
the display. This happens in the following context:
- no video mode is set before weston starts (eg no "/dev/fb" set up)
- weston is not configured with any default video mode (nothing from
weston.ini nor command line)
- the DRM driver provides with a list of supported modes, but none of them
is marked as PREFERRED (which is not a usual case, but it happens)
In that case, according to the current implementation, the DRM compositor
fails to set a video mode.
This fix lets the DRM compositor selects a video mode (the best one of the
list, which is the first) from the ones provided by the driver.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
If we fail to allocate space for a new drm_sprite, then we should
properly call drmModeFreePlane (not free) to release the drm plane.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
Bryce Harrington
Mario Kleiner
Jon Cruz
Daniel Stone
Pekka Paalanen
Derek Foreman
Giulio Camuffo
Jonny Lamb
David Herrmann
Peter Hutterer
Alvaro Fernando García
Ander Conselvan de Oliveira
Neil Roberts
Jason Ekstrand
Jonas Ådahl
Kristian Høgsberg
U. Artie Eoff
Fabien DESSENNE
Chris Michael