- Feb 16, 2018
-
-
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. v6: - Add man-page note about cms-colord. - Don't create an output just to turn it off. 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
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>
-
Pekka Paalanen authored
For the attach on an enabled output to have an effect, we need to go through drmModeSetCrtc or ATOMIC_ALLOW_MODESET. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
Pekka Paalanen authored
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>
-
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
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
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>
-
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
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
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
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. 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>
-
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
Making this function not depend on drm_head::output field through drm_output_find_by_connector() will later allow to remove the drm_head::output field before removing the unused_connectors array. This helps keeping the commit more fine-grained. drm_backend_update_unused_outputs() was only interested in enabled outputs. The new code is 100% equivalent to the old code. The difference is that weston_head::output is only set for attached heads. A connector cannot be in use if it is not attached to an output. 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. This simplifies the code a little, introduces drm_head_find_by_connector(), and works towards the eventual removal of drm_output_find_by_connector(). Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Helps debugging. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Move the responsibility of ensuring the head will work in the enabled output to the backends. A compositor cannot enable an output without heads, and removing the last head from an output automatically disables the output, so attaching a new head to an enabled output is only possible for clone mode. Backends headless, rdp, and x11 forbid clone mode by not having an attach_head hook implemented; fbdev and wayland explicitly deny clone mode. Only the DRM backend is affected by this change and even that not yet because MAX_CLONED_CONNECTORS is 1 in the DRM backend. Also ensure a global is created for the head when attached to an enabled output, and log it. 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
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
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. v6: - add missing drm_head_destroy() call 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>
-