- Dec 13, 2017
-
-
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
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. The DRM backend will simply start using the newly added connectors, and if it fails, it will keep on trying to use it. Implementing something to deal with the failure case is left for future work. Also ensure the head is properly enabled when attached to an enabled output, and log it. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Leaks spotted by Valgrind. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Spotted by Valgrind. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
Fixes the following Valgrind error: ==21607== Syscall param ioctl(generic) points to uninitialised byte(s) ==21607== at 0x5E8C787: ioctl (in /lib64/libc-2.25.so) ==21607== by 0x8220C17: drmIoctl (in /usr/lib64/libdrm.so.2.4.0) ==21607== by 0x82263CD: drmModeSetCrtc (in /usr/lib64/libdrm.so.2.4.0) ==21607== by 0x7B22095: drm_output_apply_state_legacy (compositor-drm.c:2107) ==21607== by 0x7B2335D: drm_pending_state_apply (compositor-drm.c:2539) ==21607== by 0x7B23AEB: drm_repaint_flush (compositor-drm.c:2773) ==21607== by 0x4E4A3E4: output_repaint_timer_handler (compositor.c:2500) ==21607== by 0x5081496: wl_event_source_timer_dispatch (event-loop.c:235) ==21607== by 0x5081B61: wl_event_loop_dispatch (event-loop.c:633) ==21607== by 0x50803A4: wl_display_run (wayland-server.c:1245) ==21607== by 0x409DD8: main (main.c:2644) ==21607== Address 0xffefff59a is on thread 1's stack ==21607== in frame #2, created by drmModeSetCrtc (???:) ==21607== Uninitialised value was created by a stack allocation ==21607== at 0x7B2782F: drm_output_choose_initial_mode (compositor-drm.c:4842) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
In shared-CRTC clone mode there are several wl_output globals for one weston_output. Only one panel and background is needed per weston_output, so the extra wl_outputs do not get their own panel and background. When a head is unplugged, the corresponding wl_output is removed. If that was the wl_output associated with the background and panel surfaces, we must transfer the ownership to a remaining wl_output that was a clone to avoid losing the background and panel completely. The transfer relies on desktop-shell.so implementation to register background and panel surfaces with the weston_output, not the weston_head, so it does not actually matter the wl_output used to bind the surfaces is going away. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
If for some reason the helper client weston-desktop-shell would create more than one panel surface for the same weston_output, this code would corrupt the surface destroy listener list by adding a link already in one list into another list. Instead, do not store the new, redundant panel surface and do not subscribe to its destruction. Also, tell the helper that the surface is redundant by configuring it with a 0x0 size, so that we don't waste memory on a panel that is never used. (Clone mode is a valid reason why weston-desktop-shell could do that.) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
If for some reason the helper client weston-desktop-shell would create more than one background surface for the same weston_output, this code would corrupt the surface destroy listener list by adding a link already in one list into another list. Instead, do not store the new, redundant background surface and do not subscribe to its destruction. Also, tell the helper that the surface is redundant by configuring it with a 0x0 size, so that we don't waste memory on a background that is never used. (Clone mode is a valid reason why weston-desktop-shell could do that.) Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
If for some reason the desktop-shell plugin would configure a panel with an invalid size, just destroy the whole panel and forget about it for this wl_output. A following patch will cause desktop-shell to configure 0x0 panel when it deems the panel redundant. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
If for some reason the desktop-shell plugin would configure a background with an invalid size, just destroy the whole background and forget about it for this wl_output. A following patch will cause desktop-shell to configure 0x0 background when it deems the background redundant. Fortify weston-desktop-shell against not every output having a background. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
Pekka Paalanen authored
This issue was found by inspection while investigating another bug. Remove the panel and background surface destroy listeners only if the surfaces are actually still there. If the surfaces were for some reason destroyed first, we'd have use-after-free and double-remove. 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. 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
When you need to start Weston via weston-launch, systemd unit, or any other runner, it is annoying to try to get in with a debugger, especially if the thing you are interested in happens at start-up. To make it easy, a new option is introduced. The new option, implemented both as a command line option and a weston.ini option, raises SIGSTOP early in the start-up, before the weston_compositor has been created. This allows one to attach a debugger at a known point in execution, and resume execution with SIGCONT. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Acked-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net> Reviewed-by: Ian Ray <ian.ray@ge.com>
-
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
Move it into to a new function. Following patches want to compute it elsewhere as well. No functional changes. Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
-
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>
-