- Dec 13, 2017
-
-
Pekka Paalanen authored
Add a new output section key "same-as" for configuring clone mode. An output marked "same-as" another output will be configured identically to the other output. The current implementation supports only CRTC sharing for clone mode. Independent CRTC clone mode cannot be supported until output layout logic is moved from libweston into the frontend and libweston's damage tracking issues stemming from overlapping outputs are solved. Quite a lot of infrastructure is needed to properly configure clone mode. The implemented logic allows easy addition of independent CRTC clone mode once libweston supports it. The idea is that wet_layoutput is the item to be laid out and all weston_outputs a wet_layoutput contains show exactly the same area of the desktop. The configuration logic attempts to automatically fall back to creating more weston_outputs when all heads do not work under the same weston_output. For now, the fallback path ends with an error message. Enabling a weston_output is bit complicated, because one needs to first collect all relevant heads, try to attach them all to the weston_output, and then back up head by head until enabling the weston_output succeeds. A new weston_output is created for the left-over heads and the process is repeated. CRTC-sharing clone mode is the most efficient clone mode, offering synchronized scanout timings, but it is not always supported by hardware. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Doing anything after getting SIGSEGV is sketchy to begin with, but we can still do our best. Avoid the weston_log() (timestamps!) path and stdio FILE when printing. There is no way to fall back, so we don't care if something doesn't reach the log. Just hammer a few times and give up. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Rename user_data to wet, because it is called wet everywhere else. Drop the local variable ec, because that is available as wet.compositor. This models a little better that wet_compositor owns weston_compositor, and not the other way around. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
This makes it easier to just pass wet_compositor around and take the weston_compositor from it. It feels weird to go from weston_compositor to wet_compositor all the time in internal functions. It's necessary in callbacks that cannot carry wet_compositor, but otherwise it is awkward. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Support attaching custom data to a weston_output by the traditional destroy listener / wl_signal_get approach. Needs a new destroy signal, because user data lifetime should be the lifetime of the weston_output regradless of its enabled status. The old destroy signal is for output consumers that only care about enabled outputs in the system and gets emitted on disable, not on destroy. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
To let users pick an arbitrary name for an output, to be used as e.g. a configuration key, add API to create an output with a given name. For the same configuration purpose, add a search function as well. For the search function to be predictable, forbid creating multiple outputs with the same name. Previously, creating multiple outputs with the same name would have needed detatching to create outputs from the same head, now that is forbidden. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
This will be interesting to see when testing clone mode. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
Remove the scaffolding that allowed backends to be converted one by one to the head-based API. Nothing is using these members anymore. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Fix this function to support more than one head per output. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Fix this function to support more than one head per output. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Fix this function to support more than one head per output. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
This function needs to reset the structures to NULL, otherwise it is not possible to re-use a once "freed" property info array. Being able to re-use an array is useful when the memory allocation and array lifetimes do not match. A specific example is drm_output that is changed to allocate the CRTC on enable() and deallocate it on disable(). A drm_output might be enabled and disabled multiple times. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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. The primary motivation here is to remove a user of drm_output_find_by_connector() so that a following patch can remove the function. This fixes some confusion on which connectors should have been in unused_connectors array. When an output was created due to hotplug, even before taking it into use, it would count as a used connector because of drm_output_find_by_connector() used in drm_backend_update_outputs(). OTOH, drm_output_enable() removed the connector from unused_connectors while drm_output_disable() puts the connector into unused_connectors. A connector can be both unused or not when a non-enabled output exists for it. A second hotplug event would cause drm_backend_update_outputs() to override any previous enable/disable setup. So we also relied on hotplug events to not occur before the compositor configured the new outputs. Now I realize it was meant to avoid flicker. After hotplug, if weston repaints before the compositor explicitly configures the output, this "confusion" avoids automatically turning off the connector. If the compositor chooses to drive the connector, we might flicker. However, in what circumstances can a connector be hotplugged while already active? That should only happen on compositor start-up, because later we have already disabled all connectors and CRTCs we are not using. Therefore removing the "confusion" is harmless. On compositor start-up, we detect all connected connectors and create outputs for them, and then the explicit call to weston_compositor_flush_heads_changed() will guarantee all connectors will be set up before Weston goes into the first repaint that will disable all unused connectors. What about VT-switch in? Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
I need to destroy the list from more places, so factor out the common bits. No functional changes. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
Factor out drm_output_init_crtc() and drm_output_fini_crtc(), so that the call sites can later be moved easily. In the fini path scanout_plane can be NULL if drm_output_init_crtc() fails. create_ouput_for_connector() will then call drm_output() which calls fini. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Move this bit of code into its own function. The caller of this already cluttered and origcrtc is not used for anything else. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
Switch drm_output_find_by_connector() to search for the output by iterating the compositor's head_list. drm_head_find_by_connector() will be useful later on its own. As of "compositor-drm: start migration to head-based output API" the head list is guaranteed to contain all created drm_outputs through the automatically created drm_head. Note: drm_backend_update_unused_outputs() seems to conflict with drm_output_enable()/drm_output_disable() on when a connector ID belongs in the unused_connectors array. This patch is preserving the old semantics and confusion. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Hook up the libweston facing head-based output API by introducing struct drm_head, but leave it as a fake so that members can be migrated in pieces in follow-up patches. The DRM backend continues to create an output for each connected connector only, and during output creation it also creates a drm_head for it. This allows it to pretend it supports the head-based output API as long as there is only one head per output ever attached. create_output callback is fake, it will only look up the existing drm_output by the head name. Clones are not yet supported, hence max is defined to 1. This unfortunately introduces some temporary code that will be revomed later, but seems to be necessary to avoid a single big patch. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Follow the standard pattern used in the headless and x11 backend migration, but also cater for the two other backend modes: --sprawl or fullscreen-shell, and --fullscreen. Stops relying on the implicit weston_output::head. Unlike other backends, this uses the attach_head hook to do the required head setup that is not possible to do without an output, but must be done before weston_output_enable(). This also requires the detach_head hook for the one case where the user attaches a --fullscreen head and then detaches it without enabling the output. It is a little awkward to fully initialize heads as late as attach, but aside from the --sprawl/fullscreen-shell case, there is not really a way to know the head properties without creating the parent wl_surface and configuring it. Heads/outputs created for parent outputs now have distinct names instead of all being called "wlparent". Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Add safeguards to make it painfully obvious if we ever get the pairing of wayland_backend_create_output_surface() and wayland_backend_destroy_output_surface() wrong. Helps catching bugs. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Follow the standard pattern set by the headless backend which also uses the the window output API. Stops relying on the implicit weston_output::head. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Implement the head-based output API in this backend, and stop relying on the implicit weston_output::head. The split between fbdev_head and fbdev_output is somewhat arbitrary. There is no hotplug or unplug, and there is always 1:1 relationship. Struct fbdev_screeninfo could have been split as well, but it would not have made much difference. I chose fbdev_output to carry the mmap details (buffer_length is now duplicated here), and fbdev_head to carry the display parameters and device node path. The device node identifies the head, similar to a connector. The backend init creates a head. The compositor uses it to create an output. Libweston core attaches the head automatically after creating the output. The attach hook is a suitable place to set up the video modes on the output as they are dictated by the head, it would be too late at enable() time. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Destroying the whole output in reenable would cause list walk corruption: the loop over output_list in session_notify() is not using wl_list_for_each_safe so output removal would break it. Creating a new output is also problematic as it needs the compositor to configure it, but that probably saved us from another list walk failure: adding the new output to be list while walking the list, possibly causing it to be destroyed and re-created ad infinitum. Instead of a complete destroy/create cycle, just do our internal disable/enable cycle. That will re-open the fbdev, re-read the parameters, re-create hw_surface, and reinitialize the renderer output. A problem with this is if fbdev_set_screen_info() fails. We do read the new parameters, but we don't communicate them to libweston core or old clients. However, it is hard to care: to trigger this path, one needs to VT-switch to another fbdev app which changes the fbdev parameters. That is quite difficult as VT-switching has been broken for a good while for fbdev-backend, at least with logind. Also fbdev_set_screen_info() would have to fail before one should be able to tell something is wrong. The real reason behind this patch, though, is the migration to the head-based output API. Destroying and re-creating an output really does not fit that design. Destroying and re-creating a head would be better, but again not testable in the current state. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Follow the starndard patttern as the other backends, headless and x11 in particular, to stop relying on the implicit weston_output::head. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Implement the head-based output API in this backend, and stop relying on the implicit weston_output::head. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
If the idle_repaint() callback has been scheduled when a weston_output gets destroyed, the callback will hit use-after-free. I have encountered this when migrating the wayland backend to the head-based API, using --sprawl, and closing/disconnecting one of the parent compositor outputs. Store the idle_repaint callback source, and destroy it in weston_output_release(), ensuring we don't get a stale call to start_repaint_loop later. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
The functions called here, particularly weston_output_transform_scale_init(), rely on current mode being set. The current mode must also be found in the mode list, though we don't explicitly check it here. current_mode not being set is a programmer error. It could be a backend bug, but it could also be a libweston user bug not calling a set size function. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Output make and model are not allowed to be NULL in the protocol, so ensure they are not forgotten when enabling an output. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
All frontends have been converted to the new head-based output management API, which means that weston_compositor_create_output_with_head() is calling weston_output_attach_head(). We will never hit the implicit attach anymore. Therefore we can now require that an output has at least one head when calling weston_output_enable(). An output without heads is useless. The auto-add code is removed as dead. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-