In addition to the normal touch event processing mode, introduce a new
mode for calibrating a touchscreen input device.
In the calibration mode, normal touch event processing is skipped, and
the raw events are forwarded to the calibrator instead. The calibrator
is not yet implemented, so the calls will be added in a following patch.
To switch between modes, two functions are added, one for entering each
mode. The mode switch happens only when no touches are down on any touch
device, to avoid confusing touch grabs and clients. To realise this, the
state machine has four states: prepare and actual state for both normal
and calibrator modes.
At this point nothing will attempt to change the touch event mode.
The new calibrator mode is necessary, because when calibrating a
touchscreen, the touch events must be routed to the calibration client
directly. The touch coordinates are expected to be wrong, so they cannot
go through the normal focus surface picking. The calibrator code also
cannot use the normal touch grab interface, because it needs to be able
to distinguish between different physical touch input devices, even if
they are part of the same weston_seat. This requirement makes
calibration special enough to warrant the new mode, a sort of "super
grab".
Co-developed by Louis-Francis and Pekka.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Commit a30e29af2e introduced the code to
deal with a touchscreen with touches already down when Weston starts
using it. It fixed the touchpoint counting problem.
However, Weston still should not forward or process the unmatched
touch-ups either. Code inspection says it would confuse the
idle-inhibit counting, and it could probably confuse clients as well.
Hence, just drop unmatched touch-ups.
Enhance the warning message to allow identifying where the event came
from.
v2:
- use syspath instead of devpath
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The touchpoint counting is needed regardless of what we do with the
touch events, so move it out of process_touch_normal() into the caller
notify_touch_normalized().
This is pure refactoring.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
notify_touch_normalized() is an extended form of notify_touch(), adding
normalized touch coordinates which are necessary for calibrating a
touchscreen.
It would be possible to invert the transformation and convert from
global coordinates to normalized device coordinates in input.c without
adding this API, but this way it is more robust against code changes.
Recovering normalized device coordinates is necessary because libinput
calibration matrix must be given in normalized units, and it would be
difficult to compute otherwise. Libinput API does not offer normalized
coordinates directly either, but those can be fetched by pretending the
output resolution is 1x1.
Anticipating touch calibration mode, the old notify_touch() is renamed
into a private process_touch_normal(), and the new
notify_touch_normalized() delegates to it.
Co-developed by Louis-Francis and Pekka.
v2:
- introduce struct weston_point2d_device_normalized
- rename notify_touch_cal() to notify_touch_normalized()
- remove WESTON_INVALID_TOUCH_COORDINATE
Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Relay touch input events into libweston core through the
weston_touch_device, so that the core can tell which individual physical
device they come from.
This is necessary for supporting touchscreen calibration, where one
needs to process a single physical device at a time instead of the
aggregate of all touch devices on the weston_seat.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Move calibration printing here and call do_set_calibration() from
evdev_device_set_calibration() so that all matrix setting paths print
the same way.
Print the matrix values in a matrix style to help readability, and
mention the input device.
v2:
- use 'cal' instead of 'calb' as variable name
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Introduce weston_touch_device for libweston core to track individual
touchscreen input devices. A weston_seat/weston_touch may be an
aggregation of several physical touchscreen input devices. Separating
the physical devices will be required for implementing touchscreen
calibration. One can only calibrate one device at a time, and we want to
make sure to handle the right one.
Both backends that support touch devices are updated to create
weston_touch_devices. Wayland-backend provides touch devices that cannot
be calibrated, because we have no access to raw touch coordinates from
the device - calibration is the responsibility of the parent display
server. Libinput backend provides touch devices that can be calibrated,
hence implementing the set and get calibration hooks.
Backends need to maintain an output pointer in any case, so we have a
get_output() hook instead of having to maintain an identical field in
weston_touch_device. The same justification applies to
get_calibration_head_name.
Also update the test plugin to manage weston_touch_device objects.
Co-developed by Louis-Francis and Pekka.
v2:
- Consistently use 'cal' instead of 'calb' or 'matrix'.
- change devpath into syspath
- update copyrights
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Rather than segfaulting by attempting to traverse an initially
null log handler pointer, explicitly print a message and abort.
Signed-off-by: Matt Hoosier <matt.hoosier@gmail.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
[Pekka: coding style fix]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The SURFACE_BITS_COMMAND struct has changed and some members have been moved in the
bmp field.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Allow global control of the pixman shadow buffers. The compositor can
choose whether all output use or do not use a shadow buffer with the
pixman renderer.
The option is added to the end of struct weston_drm_backend_config to
avoid bumping WESTON_DRM_BACKEND_CONFIG_VERSION.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Add a flag to pixman-renderer for initializing the output with a shadow
framebuffer. All backends were getting the shadow implcitly, so all
backends are modified to ask for the shadow explicitly.
Using a shadow buffer is usually beneficial, because read-modify-write
cycles (blending) into a scanout-capable buffer may be very slow. The
scanout framebuffer may also have reduced color depth, making blending
and read-back produce inferior results.
In some use cases though the shadow buffer might be just an extra copy
hurting more than it helps. Whether it helps or hurts depends on the
platform and the workload. Therefore let the backends control whether
pixman-renderer uses a shadow buffer for an output or not.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Pixman-renderer uses a single internal shadow buffer. It is enough to
composite the current damage into shadow, but the copy to hw buffer
needs to include the previous damage because of double-buffering in
DRM-backend.
This patch lets pixman-renderer do exactly that without compositing also
the previous damage on DRM-renderer.
Arguably weston_output should not have field previous_damage to begin
with, because it implies double-buffering, which e.g. EGL does not
guarantee. It would be better for each backend explicitly always provide
any extra damage that should be copied to hw.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Ian Ray <ian.ray@ge.com>
This issue was likely introduced by "libweston: add
weston_view_set_output()" which forgot to ensure the output destroy
listener is removed when weston_view is destroyed, leading to freed
memory being left into the list.
This was quite easy to trigger by opening and closing an application
window a few times, leading various memory corruption symptoms.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Ian Ray <ian.ray@ge.com>
Instead of desktop shell assigning view outputs directly,
use a new method, weston_view_set_output(). The method can
set up an output destroy listener to make sure that views
do not have stale output pointers.
Without this patch it is possible to end up in a scenario
where, e.g. configure_static_view() accesses memory that
has already been freed. The scenario can be provoked by
repeatedly plugging and unplugging a display. The faulty
memory accesses are reported by valgrind.
Signed-off-by: Semi Malinen <semi.malinen@ge.com>
Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Allow cloning up to 4 connectors from the same CRTC. All the
implementation bits support more than one head per output already.
Four is just an arbitary number, small but unlikely to ever be the
limiting factor in cloning since hardware is usually very restricted.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
For the attach on an enabled output to have an effect, we need to go
through drmModeSetCrtc or ATOMIC_ALLOW_MODESET.
v9:
- Add another XXX comment.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When a head is detached from an enabled output, that output needs to go
through a modeset (drmModeSetCrtc() / ATOMIC_ALLOW_MODESET) so that the
connector is actually removed from the CRTC.
This has not yet been a problem, because an output could only have one
head at a time, and would be automatically disabled on detach. It would
be a problem with clone mode.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
If we are processing a connector that does not have an existing routing,
it is possible we pick a CRTC that was previously routed to a connector
we have not enabled yet. If that happens, the latter connector cannot
preserve its routing.
Check that no other connector we might enable later had this CRTC
before.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
To support shared-CRTC clone mode, the chosen CRTC needs to support
driving all the attached connectors. Replace the old algorithm with a
new one that takes into account all associated connectors.
Ideally it should use possible_clones mask to check which encoders (and
therefore connectors) actually can be in a cloned set. However, the DRM
documentation says about possible_clones and possible_crtcs masks both:
"In reality almost every driver gets this wrong."
- https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-kms.html#c.drm_encoder
Looking at a target device and its kernel where clone mode is desired,
possible_clones is indeed self-conflicting and would not allow cloning
at all. Therefore the implemented algorithm replaces the checking of
possible_clones with luck. It even goes out of its way to find any CRTC
for a configuration, even if not advertised by the kernel as not
supported.
Libweston would need infrastructure to allow trial-and-error CRTC
allocation: rather than picking one CRTC in advance and do or die, it
should try all available CRTCs one by one. Unfortunately that is not yet
possible, so this patch implements what it can. It is also the DRM
upstream opinion that trial-and-error with ATOMIC_TEST would be the way
to go.
Unlike the old algorithm, the new algorithm prefers routings that were
in place when Weston started instead of when enabling an output. When
you never temporarily disable an output, this makes no difference.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
compositor.c has 'touch', so use 'touch' here as well. It is not a
device to begin with.
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
We have weston_seat_{init,release}_{pointer,keyboard,touch}() as the
backend-facing API. There is no need to expose the create/destroy
functions which have been for internal use only for quite a long time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
v1 Tested-by: Matt Hoosier <matt.hoosier@gmail.com>
If an input device is associated to an output that then gets disabled,
there is no case where associating to a different output would be
correct.
The output association is used for absolute positioned input devices,
and an input device like a touchscreen cannot ever be automatically
valid for more than one possible output - the touchscreen display
device.
Therefore do not automatically reassing implicitly associated input
devices to another output. This removes some log spam on shutdown.
In fact, if there can be more than one output at any time, absolute
input devices must be explicitly configured to associate with the
correct output, or the results are essentially undefined in any case.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The use case driving this change is a clone mode setup, where the user
is hotplugging or unplugging a cloned touchscreen. Even if the output
and head are force-enabled, the touch device should still follow the
connector connection status. If there is no video signal for the
touchscreen (disconnected connector), then the touch input should be
ignored as well.
When the output is force-enabled, we need to trigger
output_heads_changed from connector status changes. If the head or
output are not force-enabled, the compositor will likely attach and
detach the head as appropriate. In clone mode, the attach or detach
needs to trigger output_heads_changed directly. In other cases, it may
be handled through the output getting enabled or disabled which are
different signals.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Associating input devices with weston_outputs by the output name fails
when one output has several heads. We need to match against head names
instead of output names to be able to find all names.
This fixes touchscreen output association in shared-CRTC clone mode when
outputs or input devices appear or disappear.
Even though notify_output_create() is called only when new outputs
appear, the implementation is prepared to also remove output
associations. This will be handy in the future when this function will
handle also head detaching from an output that remains enabled.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Removing the output association from an evdev_device is more than just
setting the pointer to NULL, one also needs to remove the destroy
listener and flag the destroy listener as unused (notify == NULL).
evdev_device_set_output() can already remove associations, so let it
also handle an assignment to NULL output.
Fix notify_output_destroy() to handle removing an association correctly.
Previously, the listener was left "used", which would mean the next call
to evdev_device_set_output() would have wl_list_remove()'d, accessing
freed memory. This could be triggered by having a touchscreen with a
specified output association, and unplugging then re-plugging the
corresponding output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
In the future evdev_device_set_output() will start getting called more
often, redundantly. Short-circuit the setting if the chosen output is
already set for an input device. This reduces churn in the logs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Helps admins ensure the configuration is correct.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The udev property WL_CALIBRATION is an old way of giving Weston a
touchscreen calibration matrix. It is Weston-specific.
The recommended way of setting up a calibration is to use the udev
property LIBINPUT_CALIBRATION_MATRIX, which libinput will load
automatically and therefore applies to all libinput using display
servers and applications.
The syntax of WL_CALIBRATION and LIBINPUT_CALIBRATION_MATRIX is
different as well: WL_CALIBRATION uses pixels as the translation part
units, which makes the values depend on the output resolution.
LIBINPUT_CALIBRATION_MATRIX on the other hand uses normalized units.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Print a note that calibration got skipped if the input device supports a
calibration matrix but there is no associated output to compute it from.
Helps with debugging touchscreen calibration issues.
The code is reorganized and commented a bit, but this does not change
the behaviour.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Struct 'evdev_device' has field 'devnode' which is initialized to NULL,
never assigned, and finally free()'d. Therefore it is useless.
Remove the dead field.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The head was just zalloc()'d, there is no need to memset it to zero.
If a function fails, it is preferable it leaves the output arguments
untouched.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Rename connector_get_current_mode() because it will be useful for
storing not just the current mode on creating a head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Stop using a head for printing the mode list, because there could be
multiple heads. We already gather the mode list from all heads.
No need to print the connector id here, because it is logged with DRM
heads, and core prints the head names on output enable.
The "built-in" flag seemed dead, because it could only be printed if the
kernel provided no modes. If we want more detailed info on where modes
come from, we would need to inspect mode_info or add new flags to
drm_mode or weston_mode.
Add printing the pixel clock, because that is used by the video mode
duplicate removal code.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
If an output has multiple (cloned) heads, it should be enough for any
head to support backlight control for DRM-backend to expose it.
Inspect all attached heads for backlight control and improve the
logging.
Pick the initial backlight level from whatever happens to be the "first"
head, because it's simple.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
A single list of modes needs to be combined from the mode lists in each
attached head. We could just concatenate the lists, but that might
introduce duplicates. Try to avoid duplicates instead by using partially
fuzzy matching.
When a duplicate is found, try to figure out which is more suitable to
use in place of both. If one has the preferred flag and the other
doesn't, take the preferred one. Otherwise use the one already in the
list.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Previously the log contained one line for EDID data and another line for
the head, and you just had to know they belong together. Make it more
obvious to read by putting both head and EDID info on the same line.
We no longer print EDID data every time it is parsed (on every hotplug
event), but only if it changes. I did take a shortcut here and use
weston_head::device_changed as the print condition which relies on the
compositor clearing it, but a failure to do so just means we print stuff
even if it didn't change.
Head info updates also print the head info and not just the EDID data.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Fix this function to support more than one head per output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Fix this function to support more than one head per output.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Fix this function to support more than one head per output.
v9:
- Change { connectors, 0 } to { NULL, 0 } in drmModeSetCrtc() args.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Replace the unused_connectors array by iterating through the head list
instead. A head that is not enabled (attached to an enabled output) is
basically an unused connector.
All connectors regardless of their status have a drm_head. This has the
nice effect that drm_pending_state_apply_atomic() does not need to
re-query the connector properties every time, they can be simply looked
up in the drm_head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
In previous patches, all the appropriate fields from drm_output have
been moved into drm_head, and resource allocation has been moved away
from drm_output creation. It is time to throw the switch: this patch
disconnects the drm_output and drm_head lifetimes.
Previously a drm_output was created for a connected connector and
destroyed on disconnection. A drm_head was tied to the drm_output
lifetime just to accommodate the head-based output configuration API
temporarily.
Now all connectors will get a head created regardless of their
connection status. Heads are created and destroyed as connectors appear
and disappear (MST), not when they get connected or disconnected. This
should allow the compositor to force-enable a disconnected connector.
An "empty" drm_output is created with weston_backend::create_output()
hook. This now follows the intent of the head-based output configuration
API.
On hotplug events, all connectors' information is updated regardless of
their connection status changes. It is theoretically possible for a
monitor to change without going through a disconnected state in between.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Move the initialization of the drm_output mode list to
drm_output_set_mode() time.
Once we stop creating the drm_head with the drm_output, there will not
be a head to get the mode list from at drm_output creation time.
Furthermore, once DRM-backend starts supporting more than one head per
output, the combined mode list to be exposed to clients (and the
compositor?) must be constructed with all heads attached.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The inherited mode is the video mode on the connector when we have not
yet reconfigured the connector, if set.
Get the inherited mode the moment we create a drm_head, not when we
determine the mode for a drm_output. This way we are sure to read all
inherited modes before we reconfigure a single CRTC. Enabling one output
may grab the CRTC from another connector, overwriting whatever mode that
connector might have had.
The inherited mode is stored in drm_head, where we can keep it for the
lifetime of the head, rather than relying on re-loading it from the
kernel at set_mode() time.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
As these planes are allocated on output enable and freed on output
disable, there cannot be a match in the pending_output_list.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
As CRTC is allocated on output enable and deallocated on output disable,
there cannot be any matches in find-by-crtc from the
pending_output_list.
Remove the loop over pending_output_list as never finding anything by
definition.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
A drm_output needs a CRTC only when it is in use. Allocating a CRTC on
creation of drm_output will reserve the CRTC regardless of whether the
output is actually used or not. This may cause creating other
drm_outputs to fail if there are not enough CRTCs.
Instead, allocate the CRTC on drm_output enable() time. A drm_output
will have a valid CRTC only while it is enabled.
This allows us to create drm_output objects arbitrarily and without a
head assignment, which is required by the head-based output API for the
backends. The assigned heads will be known only at enable() time.
Now drm_output_enable() has to call drmModeGetResources() to be able to
find a suitable CRTC. We might want to cache the resources somewhere,
but that is it topic for another patch.
v4: Force resetting unused CRTCs on fini.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Move the connector related fields from drm_output to the drm_head. A
drm_head represents a connector for now.
The code in drm_head_create() to update connector data, monitor
information, etc. is moved into a new function. This will be useful when
DRM-backend starts creating heads for all connectors regardless of their
connection status and will need to update them on hotplug events.
While incurring the churn to move several fields into struct drm_head,
also refactor out drm_head_assign_connector_info(). This function is
needed later when drm_heads will exist regardless of connected status,
as every hotplug event will need to update the state of all connectors.
At that point we will also start handling connector changes that do not
go through an intermediate disconnected state. This refactoring is
trivial enough to be in this patch to reduce the total amount of changes
to be reviewed.
v6:
- adapt to the new places of updating unused_connectors
- free connector in create_output_for_connector() error path
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Backlight is driven per connector, hence it belongs in struct drm_head.
weston_output::set_backlight() API is remains per output so far. There
is no UI to control backlights per head and adding one would be
difficult for an output that has multiple cloned heads.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Instead of iterating output_list and pending_output_list, iterate
head_list to find outputs whose connectors have been disconnected.
This helps a following patch to move connector fields from drm_output to
drm_head.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Louis-Francis Ratté-Boulianne
Pekka Paalanen
Matt Hoosier
David Fort
Semi Malinen