Commits on Source (11)
-
* This prevents issues from creeping back in at a later stage.
3aa754c3 -
When a GPU is auto-bound adding more outputs to a screen, that needs to count as a configuration change on that screen so that a WM listening for RRScreenChangeNotify gets notified and handles it as a hotplug. This is particularly for cases where the outputs are already connected. Otherwise nothing might happen. Issue #909 describes a real world case where plugging in a DisplayLink dock with a monitor already connected is sometimes left inactive by GNOME. That issue is a race, and requires adding a sleep(5); as the first thing in NewGPUDeviceRequest() to reproduce reliably. With the sleep, the monitor in the dock will never activate automatically. Add this fix over the sleep, and the issue is gone. This fix was originally developed on a branch replicating Ubuntu 19.04 patch set based on xserver 1.20.4. Testing on master branch was impossible due to #910. Closes: #909 Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
bfb36a58 -
Michel Dänzer authored
Fixes: cb1b1e18 "modesetting: Indirect the glamor API through LoaderSymbol" Reviewed-by: Adam Jackson <ajax@redhat.com>
0cb9fa79 -
Michel Dänzer authored
Resulted in a build failure with -Werror: ../hw/xfree86/drivers/modesetting/drmmode_display.c: In function ‘drmmode_crtc_set_mode’: ../hw/xfree86/drivers/modesetting/drmmode_display.c:759:15: error: unused variable ‘screen’ [-Werror=unused-variable] 759 | ScreenPtr screen = crtc->scrn->pScreen; | ^~~~~~ Fixes: c66c548e "modesetting: Call glamor_finish from drmmode_crtc_set_mode" Reviewed-by: Adam Jackson <ajax@redhat.com>
49553049 -
Michel Dänzer authored
It's long and kind of redundant. Reviewed-by: Adam Jackson <ajax@redhat.com>
72ccd7f5 -
Michel Dänzer authored
To prevent breakage with glamor disabled from creeping in again. Reviewed-by: Adam Jackson <ajax@redhat.com>
1310346d -
Michel Dänzer authored
This reverts commit 9e85aa9c. To be replaced with a better solution. Reviewed-by: Adam Jackson <ajax@redhat.com>
7b33c2d3 -
Michel Dänzer authored
The first phase sets the new surface properties for all damaged windows, then the second phase commits all surface updates. This is preparatory for the next change, there should be no observable change in behaviour (other than the order of Wayland protocol requests). Reviewed-by: Adam Jackson <ajax@redhat.com>
f88d9b1f -
Michel Dänzer authored
In between the two phases introduced by the previous change. This makes sure all pending drawing to the new buffers is flushed before they're committed to the Wayland server.
a542224e -
xf86platformProbeDev didn't check the device path, fix it. This is a problem when trying to set up a non-PCI device via explicit xorg.conf.d configuration. An USB DisplayLink device, being non-PCI was always set up as a GPU device assigned to screen 0 instead of a regular framebuffer, potentially having its own dedicated screen, despite such configuration as below. Only the relevant parts of the configuration are quoted, it's part of a larger context with an Intel chip that has 3 outputs: * DP1 connected to an LCD panel, * VGA1 connected to an external monitor, * HDMI1 unconnected and having no user visible connector Section "ServerFlags" Option "AutoBindGPU" "false" EndSection ... Section "Device" Identifier "Intel2" Driver "intel" BusID "PCI:0:2:0" Screen 2 Option "Monitor-HDMI1" "HDMI1" Option "ZaphodHeads" "HDMI1" EndSection Section "Device" Identifier "UDL" Driver "modesetting" Option "kmsdev" "/dev/dri/card0" #BusID "usb:0:1.2:1.0" Option "Monitor-DVI-I-1" "DVI-I-1" Option "ShadowFB" "on" Option "DoubleShadow" "on" EndSection ... Section "Screen" Identifier "SCREEN2" Option "AutoServerLayout" "on" Device "UDL" GPUDevice "Intel2" Monitor "Monitor-DVI-I-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "ServerLayout" Identifier "LAYOUT" Option "AutoServerLayout" "on" Screen 0 "SCREEN" Screen 1 "SCREEN1" RightOf "SCREEN" Screen 2 "SCREEN2" RightOf "SCREEN1" EndSection On the particular machine I was trying to set up an UDL device, I found the following structure was being used to match the device to a platform device while I was debugging the issue: xf86_platform_devices[0] == Intel, /dev/dri/card1, primary platform device xf86_platform_devices[1] == UDL, /dev/dri/card0 devList[0] == "Intel0", ZaphodHeads: DP1 devList[1] == "Intel1", ZaphodHeads: VGA1 devList[2] == "UDL" devList[3] == "Intel2", ZaphodHeads: HDMI1 (intended GPU device to UDL) When xf86platformProbeDev() matched the UDL device, the BusID check failed in both cases of: * BusID "usb:0:1.2:1.0" was specified * Option "kmsdev" "/dev/dri/card0" was specified As a result, xf86platformProbeDev() went on to call probeSingleDevice() with xf86_platform_devices[0] and devList[2], resulting in the UDL device being set up as a GPU device assigned to the first screen instead of as a framebuffer on the third screen as the configuration specified. Checking Option "kmsdev" in code code may be a layering violation. But the modesetting driver is actually part of the Xorg sources instead of being an external driver, so he "kmsdev" path knowledge may be used here. Signed-off-by: Böszörményi Zoltán <zboszor@pr.hu>
42aaf372 -
Adam Jackson authoredee9f6e20