The kernel is supposed to set this when drmModeSetCrtc() is called but
at least the i915 driver wouldn't do that in all cases. A fix for this
should be released with kernel 3.10, but we work around the issue in
older kernels by always forcing DPMS to ON when doing a mode set.
https://bugs.freedesktop.org/show_bug.cgi?id=64873
We changed the protocol to always list modes in physical pixel
units (not scaled). And we removed the scaled mode flag. This
just updates the DRM and X11 compositors and the gl and pixman renderers
to handle this.
If you specify e.g. scale=2 in an output section in weston.ini
we scale all modes by that factor.
We also correctly scale cursor positioning, but ATM there is no
scaling of the cursor sprite itself.
If you specify e.g. scale=2 in weston.ini an output section for the
X11 backend we automatically upscale all normal surfaces by this
amount. Additionally we respect a buffer_scale set on the buffer to
mean that the buffer is already in a scaled form.
This works with both the gl and the pixman renderer. The non-X
backends compile and work, but don't support changing the output
scale (they do downscale as needed due to buffer_scale though).
This also sends the new "scale" and "done" events on wl_output,
making clients aware of the scale.
This set of changes adds support for searching for a given config file
in the directories listed in $XDG_CONFIG_DIRS if it wasn't found in
$XDG_CONFIG_HOME or ~/.config. This allows packages to install custom
config files in /etc/xdg/weston, for example, thus allowing them to
avoid dealing with home directories.
To avoid a TOCTOU race the config file is actually open()ed during the
search. Its file descriptor is returned and stored in the compositor
for later use when performing subsequent config file parses.
Signed-off-by: Ossama Othman <ossama.othman@intel.com>
The function drm_output_start_repaint_loop() unconditionally issues a
page flip, even if the crtc for that output has not been enabled yet.
That causes the page flip to fail, and drm_output_repaint() is never
called.
Solve this by bypassing the initial page flip if the output needs a
mode set.
This has the caveat of affecting latency predictability for that first
frame and when a "driver" mode fullscreen surface causes a mode set.
However, on both cases the mode set would take an unpredictable amount
of time anyway.
https://bugs.freedesktop.org/show_bug.cgi?id=63812https://bugs.freedesktop.org/show_bug.cgi?id=64183
in drm_fb_create_dumb, the return value of the drmIoctl function call
to map the dumb buffer was never checked, thus the following "if
(ret)" check was invalid as it was checking the previous return value
from the above drmModeAddFB call.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
Most backends relies on gettimeofday(2) for output repaint timestamps
but this is not a requirement. Before this patch repaints coming from
idle_repaint() always used gettimeofday(2) for timestamps. For backends
not using that time source this could cause large jumps between
timestamps.
To fix this, timestamps needs to always come from the backend. This
means that the backend needs to always be responsible of starting the
repaint loop in case that the repaint cannot start immediately.
The drm backend implementation is from the patch by Ander Conselvan de
Oliveira found here:
http://lists.freedesktop.org/archives/wayland-devel/2013-February/007393.html
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
This state is used when the user switches the vt. It turns of rendering
and frame events, but doesn't set the DPMS state to off.
As a part of this change, also turn off the idle timer when entering
the SLEEPING or OFFSCREEN states, which fixes
https://bugs.freedesktop.org/show_bug.cgi?id=61910 (rpi backend
untested).
We subtract the screen space opaque region from the transformed surface
region. That's going to fail for when we're scaling up a surface, since
the surface bounding box for the scaled up surface is going to be bigger
than the opaque region. Instead, subtract the surface-space opaque region
from a 0,0 - width,height region and see if that's empty.
If there was a fullscreen surface using driver mode when a vt switch is
triggered, but something caused it to be gone when switching back (such
as the client being killed), a call to drm_output_switch_mode() is made
to restore the old mode, and that sets the output's current drm_fb to
NULL, so that the new mode is set drm_output_repaint(). This led to a
crash in vt_func(), because it tried to access output->current for
restoring the old mode.
Fix this by not setting the mode if there's no current fb. Instead,
schedule a repaint so that the mode is set in drm_output_repaint().
https://bugs.freedesktop.org/show_bug.cgi?id=60675
We always call enable_udev_monitor and add_devices together and always
disable_udev_monitor and remove_devices together. Let's just have one
entry point for enable and one for disable.
We used to have a bit of naming trouble when the protocol object was called
wl_input_device and the individual evdev devices were call evdev_device.
And we didn't have a drm_seat. Now that we've fixed all that, it's clear
that the drm_seat is all about udev discovery and hotplug of evdev devices,
so let's call it udev_seat instead.
Otherwise we'll kill whatever other display sever we're switching back to.
The tricky thing here is that we never explicitly set drm master in the
startup path, we get that implicitly from being the first to open the
drm device. Even so, we need to drop it before switching VTs.
The drm planes (sprites) only support translation and scaling. Now that
we have matrix.type, we can just look there to see if the transform is
compatible with kms.
Call drm_output_init_egl() instead of duplicating the gbm surface and
gl renderer state initialization code.
Note that this makes error handling a bit worse. Before, if we failed
to allocate a gbm surface we could still recover. Failing the renderer
state creation would lead to inconsisten state. Now we end up in
inconsistent state on both cases.
At this point, we reallocated the gbm surface, but we don't have an
fb with the right size to use. If we're going to a larger mode, the fb
would be too small and the mode set would fail. Besides, the repaint
logic will already do a mode set if necessary, so rely on that instead.
After a mode switch, the output region and transformation matrix need
to be updated. The call to weston_output_move() would do the former but
not the latter, but calling that when the output remains in the same
coordinate doesn't make much sense. Instead, update this state and the
transformation matrix in weston_output_mode_switch().
Trying to create a ARGB framebuffer for scanout results in EINVAL when
trying to queue the pageflip. This patch overrides the format we pass
to addfb2 in case of primary buffers like we do for sprites.
Since we always have to inspect and override the format, don't try to
look up the format in drm_fb_get_from_bo(). Instead return format from
drm_output_check_scanout_format().
Rename drm_surface_format_supported() to drm_output_check_sprite_format()
and make it follow the same convention.
We started scanning out ARGB surfaces in commit e920941032.
Since the call to drmModeSetPlane() fails with EINVAL if the supplied
fb has an unsupported format (which is the case of ARGB8888), the fb
format needs to be overridden.
Make overlays work when the client uses a buffer with the same
transformation as the output.
In order to calculate the destination rectangle, the same logic in
weston_surface_to_buffer_float() is needed, but with the output
dimensions instead. For that reason, this patch generalizes this
function into weston_transformed_{coord,rect} and moves it to util.c.
The surface functions are then implemented using those.
A client can reliably avoid allocating a second buffer per surface, if
the compositor sends the wl_buffer.release event before the frame
callback. To enable clients' single-buffering, release the wl_buffer
early if possible. Otherwise clients will double-buffer.
Releasing early is not possible, if the backend needs the buffer for
migrating a surface to or from a non-primary weston_plane. In that case,
a new buffer must arrive, before the old can be released. Backends will
indicate this by setting weston_surface:keep_buffer to 1 in
assign_planes().
A proper buffer reference in the backends would be better than the
keep_buffer flag, but that would require a per-surface backend private.
The rpi and DRM backends are updated to set keep_buffer, other backends
do not support planes, so do not have to set it.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>
The wl_buffer reference counting API has been inconsistent. You would
manually increment the refcount and register a destroy listener, as
opposed to calling weston_buffer_post_release(), which internally
decremented the refcount, and then removing a list item.
Replace both cases with a single function:
weston_buffer_reference(weston_buffer_reference *ref, wl_buffer *buffer)
Buffer is assigned to ref->buffer, while taking care of all the refcounting
and release posting. You take a reference by passing a non-NULL buffer, and
release a reference by passing NULL as buffer. The function uses an
internal wl_buffer destroy listener, so the pointer gets reset on
destruction automatically.
This is inspired by the pipe_resource_reference() of Mesa, and modified
by krh's suggestion to add struct weston_buffer_reference.
Additionally, when a surface gets destroyed, the associated wl_buffer
will send a release event. Often the buffer is already destroyed on
client side, so the event will be discarded by libwayland-client.
Compositor-drm.c is converted to use weston_buffer_reference.
Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>