path: root/hw/xfree86
AgeCommit message (Collapse)AuthorFilesLines
2020-05-10Update URL's in man pagesAlan Coopersmith2-5/+5
Mostly http->https conversions, but also replaces gitweb.fd.o with gitlab.fd.o, and with Signed-off-by: Alan Coopersmith <>
2020-04-30hw/xfree86: Support ACPI without APM.Tobias Stoeckmann1-4/+5
On systems with ACPI but disabled APM (e.g. --disable-linux-apm) the code does not compile due to preprocessor directives. If APM is disabled, the final return statement is considered to be part of ACPI's last if-statement, leading to a function which has no final return statement at all. I have refactored the code so ACPI and APM are independent of each other. Signed-off-by: Tobias Stoeckmann <>
2020-04-10Xorg: honor AutoRepeat optionMichael Stapelberg1-0/+28
This option was implemented before the drivers were split in ≈2006, and e.g. XWin still supports it. With this commit, Xorg regains support, so that the following configuration can be used to set the repeat rate for all keyboard devices without having to modify Xorg command-line flags or having to automate xset(1): Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "de" Option "XkbVariant" "neo" Option "AutoRepeat" "250 30" EndSection Signed-off-by: Michael Stapelberg <>
2020-03-13modesetting: add support for GBM_FORMAT_ARGB1555Yuriy Vasilev1-4/+12
Reviewed-by: Michel Dänzer <> Signed-off-by: Yuriy Vasilev <>
2020-03-13modesetting: add support for GBM_FORMAT_RGB565Yuriy Vasilev1-0/+2
This allow x-server to run with -depth 16. Reviewed-by: Michel Dänzer <> Signed-off-by: Yuriy Vasilev <>
2020-02-12Fix modesetting device matching through kmsdev device pathZoltán Böszörményi1-1/+9
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 <>
2020-02-11modesetting: Remove local variable only used with glamor enabledMichel Dänzer1-2/+1
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: c66c548eabf0 "modesetting: Call glamor_finish from drmmode_crtc_set_mode" Reviewed-by: Adam Jackson <>
2020-02-10modesetting: Fix build with glamor disabledMichel Dänzer2-7/+17
Fixes: cb1b1e184723 "modesetting: Indirect the glamor API through LoaderSymbol" Reviewed-by: Adam Jackson <>
2020-02-06modesetting: remove unnecessary error message, fix zaphod leasesDave Airlie1-4/+5
I introduced this error with the MST hotplug code, but it can trigger on zaphod setups, and is perfectly fine. There is no support for MST/hotplug on zaphod setups currently, so we can just skip over the dynamic connector handling here. However we shouldn't skip over the lease handling so move it into the codepath. Fixes: 9257b1252da9 ("modesetting: add dynamic connector hotplug support (MST) (v3)") Reviewed-by: Michel Dänzer <> Signed-off-by: Dave Airlie <>
2020-01-30xfree86/modes: Bail from xf86RotateRedisplay if pScreen->root is NULLMichel Dänzer1-1/+1
Avoids a crash in xf86RotatePrepare -> DamageRegister during CreateScreenResources if rotation or another transform is configured for any connected RandR output in xorg.conf. The generic rotation/transform code generally can't work without the root window currently. Closes: Fixes: 094f42cdfe5d "xfree86/modes: Call xf86RotateRedisplay from xf86CrtcRotate" Acked-by: Olivier Fourdan <> Reviewed-by: Adam Jackson <>
2020-01-28loader: strdup const string assigned to local variable nameMichel Dänzer1-1/+1
There's a free(name) at the end of the function. GCC warned about this: ../hw/xfree86/loader/loadmod.c: In function ‘LoadModule’: ../hw/xfree86/loader/loadmod.c:702:18: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers] 702 | m = name = "int10"; | ^
2020-01-14modesetting: Explicitly #include "mi.h"Michel Dänzer1-0/+1
For the miClearDrawable prototype. Apparently it doesn't get pulled in for some build configurations, breaking the build. Reviewed-by: Kenneth Graunke <>
2020-01-08hw/xfree86/common/xf86Init.c: fix build without glxFabrice Fontaine1-1/+0
Since commit d8ec33fe0542141aed1d9016d2ecaf52da944b4b, an include on glxvndabi.h has been added to hw/xfree86/common/xf86Init.c However, if glx is disabled through --disable-glx and GLX headers are not installed in the build's environment, build fails on: In file included from xf86Init.c:81: ../../../include/glxvndabi.h:64:10: fatal error: GL/glxproto.h: No such file or directory 64 | #include <GL/glxproto.h> | ^~~~~~~~~~~~~~~ Fix this failure by removing this include which does not seem to be needed (an other option would have been to keep it under an ifdef GLXEXT block) Fixes: - Signed-off-by: Fabrice Fontaine <>
2020-01-03modesetting: Check whether RandR was initialized before calling rrGetScrPrivAaron Plattner3-6/+20
Calling rrGetScrPriv when RandR isn't initialized causes an assertion failure that aborts the server: Xorg: ../include/privates.h:121: dixGetPrivateAddr: Assertion `key->initialized' failed. Thread 1 "Xorg" received signal SIGABRT, Aborted. 0x00007ffff78a8f25 in raise () from /usr/lib/ (gdb) bt #0 0x00007ffff78a8f25 in raise () from /usr/lib/ #1 0x00007ffff7892897 in abort () from /usr/lib/ #2 0x00007ffff7892767 in __assert_fail_base.cold () from /usr/lib/ #3 0x00007ffff78a1526 in __assert_fail () from /usr/lib/ #4 0x00007ffff7fb57c1 in dixGetPrivateAddr (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:121 #5 0x00007ffff7fb5822 in dixGetPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:136 #6 0x00007ffff7fb586a in dixLookupPrivate (privates=0x555555ab1b60, key=0x555555855720 <rrPrivKeyRec>) at ../include/privates.h:166 #7 0x00007ffff7fb8445 in CreateScreenResources (pScreen=0x555555ab1790) at ../hw/xfree86/drivers/modesetting/driver.c:1335 #8 0x000055555576c5e4 in xf86CrtcCreateScreenResources (screen=0x555555ab1790) at ../hw/xfree86/modes/xf86Crtc.c:744 #9 0x00005555555d8bb6 in dix_main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/main.c:214 #10 0x00005555557a4f0b in main (argc=4, argv=0x7fffffffead8, envp=0x7fffffffeb00) at ../dix/stubmain.c:34 This can happen, for example, if the server is configured with Xinerama and there is more than one X screen: Section "ServerLayout" Identifier "crash" Screen 0 "modesetting" Screen 1 "dummy" RightOf "modesetting" Option "Xinerama" EndSection Section "Device" Identifier "modesetting" Driver "modesetting" EndSection Section "Screen" Identifier "modesetting" Device "modesetting" EndSection Section "Device" Identifier "dummy" Driver "dummy" EndSection Section "Screen" Identifier "dummy" Device "dummy" EndSection The problem does not reproduce if there is only one X screen because of this code in xf86RandR12Init: #ifdef PANORAMIX /* XXX disable RandR when using Xinerama */ if (!noPanoramiXExtension) { if (xf86NumScreens == 1) noPanoramiXExtension = TRUE; else return TRUE; } #endif Fix the problem by checking dixPrivateKeyRegistered(rrPrivKey) before calling rrGetScrPriv. This is similar to what the xf86-video-amdgpu driver does: Signed-off-by: Aaron Plattner <> Reviewed-by: Michel Dänzer <>
2019-12-23modesetting: Fix msSharePixmapBacking Segfault RegressionAlex Goins1-2/+3
Commit cb1b1e184 modified msSharePixmapBacking() to derive modesettingPtr from the 'screen' argument. Unfortunately, the name of the argument is misleading -- the screen is the slave screen. If the master is modesetting, and the slave is not modesetting, it will segfault. To fix the problem, this change derives modesettingPtr from ppix->drawable.pScreen. This method is already used when calling ms->glamor.shareable_fd_from_pixmap() later in the function. To avoid future issues, this change also renames the 'screen' argument to 'slave'. Signed-off-by: Alex Goins <> Reviewed-by: Michel Dänzer <>
2019-11-26modesetting: Use EGL_MESA_query_driver to select DRI driver if possibleKenneth Graunke4-4/+29
New now ask Glamor to use EGL_MESA_query_driver to obtain the DRI driver name; if successful, we use that as the DRI driver name. Following the existing dri2.c logic, we also use the same name for the VDPAU driver, except for i965 (and now iris), where we switch to the "va_gl" fallback. This allows us to bypass the PCI ID lists in xserver and centralize the driver selection mechanism inside Mesa. The hope is that we no longer have to update these lists for any future hardware.
2019-11-25modesetting: Use glamor_clear_pixmap in drmmode_clear_pixmapMichel Dänzer3-0/+10
Should be slightly more efficient. Reviewed-by: Adam Jackson <>
2019-11-25modesetting: Clear new screen pixmap storage on RandR resizeMichel Dänzer1-0/+15
Fixes random garbage being visible intermittently. Reviewed-by: Adam Jackson <>
2019-11-25xfree86/modes: Call xf86RotateRedisplay from xf86CrtcRotateMichel Dänzer1-0/+3
If a new rotate buffer was allocated. This makes sure the new buffer has valid transformed contents when it starts being displayed. Reviewed-by: Adam Jackson <>
2019-11-25modesetting: Call glamor_finish from drmmode_crtc_set_modeMichel Dänzer1-3/+7
This makes sure any pending drawing to a new scanout buffer will be visible from the start. This makes the finish call in drmmode_copy_fb superfluous, so remove it. Reviewed-by: Adam Jackson <>
2019-11-25modesetting: Add glamor_finish() convenience macroMichel Dänzer2-1/+3
This will simplify backporting the following fix to the 1.20 branch. Reviewed-by: Adam Jackson <>
2019-11-22xfree86: Test presence of isastream()Matt Turner1-2/+3
isastream() was never more than a stub in glibc, and was removed in glibc-2.30 by commit a0a0dc83173c ("Remove obsolete, never-implemented XSI STREAMS declarations"). Bug: Reviewed-by: Julien Cristau <> Signed-off-by: Matt Turner <>
2019-11-21Revert "Revert "modesetting: Indirect the glamor API through LoaderSymbol""Adam Jackson6-26/+82
Now that we've fixed LoaderSymbolFromModule this should work properly. This reverts commit 5c7c6d5cffa98e4749185af9211d7642b57673d8. Reviewed-by: Michel Dänzer <>
2019-11-21loader: Make LoaderSymbolFromModule take a ModuleDescPtrAdam Jackson2-2/+3
The thing you get back from xf86LoadSubModule is a ModuleDescPtr, not a dlsym handle. We don't expose ModuleDescPtr to the drivers, so change LoaderSymbolFromModule to cast its void * argument to a ModuleDescPtr. Reviewed-by: Michel Dänzer <>
2019-11-15Revert "modesetting: Indirect the glamor API through LoaderSymbol"Michel Dänzer6-82/+26
This reverts commit dd63f717fe8636315343f421f4f2ee299258f079. Caused a crash at least on some systems. Closes:
2019-11-13modesetting: Indirect the glamor API through LoaderSymbolAdam Jackson6-26/+82
Prerequisite for building all of xserver with -z now. Gitlab:
2019-11-13modesetting: Indirect the shadow API through LoaderSymbolAdam Jackson2-20/+26
Prerequisite for building all of xserver with -z now. Gitlab:
2019-11-13loader: Move LoaderSymbolFromModule() to public APIAdam Jackson2-1/+1
Bare LoaderSymbol() isn't really a great API, this is more of a direct map to dlsym like you want. Gitlab:
2019-11-13xfree86: Call ScreenInit for protocol screens before GPU screensAaron Plattner1-25/+25
During startup, the xfree86 DDX's InitOutput() calls PreInit for protocol screens first, and then GPU screens. On teardown, dix_main() calls CloseScreen in the reverse order: GPU screens first starting with the last one and then working backwards, and then protocol screens also in reverse order. InitOutput() calls ScreenInit in the wrong order: for GPU screens first and then for protocol screens. This causes a problem for drivers that have global state that is tied to the first screen that calls ScreenInit. Fix this by simply re-ordering the for loops to call PreInit for protocol screens first and then for GPU screens second.
2019-11-11modesetting: Implement ms_covering_randr_crtc() for ms_present_get_crtc()Alex Goins3-5/+108
ms_present_get_crtc() returns an RRCrtcPtr, but derives it from a xf86CrtcPtr found via ms_dri2_crtc_covering_drawable()=>ms_covering_crtc(). As a result, it depends on all associated DIX ScreenRecs having an xf86CrtcConfigPtr DDX private. Some DIX ScreenRecs don't have an xf86CrtcConfigPtr DDX private, but do have an rrScrPrivPtr DDX private. Given that we can derive all of the information we need from RandR, we can support these screens by avoiding the use of xf86Crtc. This change implements an RandR-based path for ms_present_get_crtc(), allowing drawables to successfully fall back to syncing to the primary output, even if the slave doesn't have an xf86CrtcConfigPtr DDX private. Without this change, if a slave doesn't have an xf86CrtcConfigPtr DDX private, drawables will fall back to 1 FPS if they overlap an output on that slave. Signed-off-by: Alex Goins <>
2019-11-11modesetting: Fix ms_covering_crtc() segfault with non-xf86Crtc slaveAlex Goins1-0/+4
DIX ScreenRecs don't necessarily have an xf86CrtcConfigPtr DDX private. ms_covering_crtc() assumes that they do, which can result in a segfault. Update ms_covering_crtc() to check the XF86_CRTC_CONFIG_PTR() returned pointer before dereferencing it. This will still mean that ms_covering_crtc() can't fall back to the primary output when a drawable overlaps a slave output (going to the 1 FPS default instead), but it won't segfault. Signed-off-by: Alex Goins <>
2019-11-11modesetting: Fix ms_covering_crtc() segfault with non-modesetting slave primaryAlex Goins1-1/+34
ms_covering_crtc() uses RRFirstOutput() to determine a primary output to fall back to if a drawable is overlapping a slave output. If the primary output is a slave output, RRFirstOutput() will return a slave output even if passed a master ScreenPtr. ms_covering_crtc() dereferences the output's devPrivate, which is invalid for non-modesetting outputs, and can crash. Changing RRFirstOutput() could have unintended side effects for other callers, so this change replaces the call to RRFirstOutput() with ms_first_output(). ms_first_output() ignores the primary output if it doesn't match the given ScreenPtr, choosing the first connected output instead. Signed-off-by: Alex Goins <>
2019-10-30mi: Add a default no-op miSourceValidateAdam Jackson2-5/+4
Slightly simplifies the callers since they don't need to check for non-NULL anymore. I do extremely hate the workarounds here to suppress misprite taking the cursor down though. Surely there's a better way. Reviewed-by: Michel Dänzer <>
2019-10-30include: Remove now-empty site.hAdam Jackson2-2/+0
2019-10-29modesetting: Fix possible_crtcsVille Syrjälä1-2/+2
Populate outout possible_crtcs as the union of possible_crtcs from the encoders rather than the intersection. Otherwise we're easily left with possible_crtcs==0 when all the possible encoders have non-overlapping possible_crtcs. No idea what the magic 0x7f is about, but keep it around in case it matters. Signed-off-by: Ville Syrjälä <>
2019-10-23modesetting: typo in drmmode_display.c -- ',' instead of ';' at end of lineKeith Packard1-1/+1
This seems like a simple typo to me; thanks to C it isn't caught by the compiler. Signed-off-by: Keith Packard <>
2019-10-14Revert Dänzer2-8/+2
Caused assertion failures / crashes with Xorg. Closes:
2019-10-11glamor_egl: disable modifiers via glamor_init()Emil Velikov1-1/+7
Currently we parse through xf86Info.debug to check if we the modifiers should be disabled. Handle that within DDX and pass GLAMOR_NO_MODIFIERS into the glamor_init() flags. This allows individual DDX control over the setting - say when modifiers are woking OK with one implementation and not the other. Most importantly, this removes the final xf86 piece from the codebase. Signed-off-by: Emil Velikov <>
2019-10-11glamor_egl: don't use ScrnInfoRec::privatesEmil Velikov1-1/+1
Move from the xf86 specific ScrnInfoRec::privates, to the dix private handling. Since there's no FreeScreen function in ScreenPtr, fold the former within the existing CloseScreen. Users, such as modesetting are updated, and out of tree drivers will need equivalent, yet trivial, patch. Note: we need to ensure that the screen private is unset and the screen callbacks are restored in our CloseScreen function. Signed-off-by: Emil Velikov <>
2019-10-04modesetting: Fix broken manpage in autoconf buildSven Joachim1-6/+2
The autoconf build for the modesetting driver still relied on xorg-macros.m4 for string replacements and did not include the top-level As a result, no substitutions took place after commit 2e497bf887aca832dc0dd30d071c5288ab5c1e15. This should be a candidate for the 1.20 branch. Reviewed-by: Michel Dänzer <>
2019-10-02xfree86: Merge vbe into int10Adam Jackson13-65/+17
There's not really a good reason to keep these separate, the vbe code requires int10 and is not very large. This change eliminates the build-time options for vbe; if you build int10, you get vbe. Gitlab: Reviewed-by: Emil Velikov <>
2019-10-01Fix various spelling errorsSven Joachim5-5/+5
2019-09-30dri2: Set fallback driver names for Intel and AMD chipsAdam Jackson1-7/+2
i965 and radeonsi, respectively, are the drivers that have been receiving new hardware support. It's really silly to need to update the server side to know specific new devices IDs every time a new ASIC comes out. Reviewed-by: Michel Dänzer <>
2019-09-30modesetting: Reduce "glamor initialization failed" message to X_INFOAdam Jackson1-1/+1
This might be an error or not, for example refusing to work on llvmpipe is normal and expected. glamor_egl_init() will print X_ERROR messages if appropriate, so we don't need to here. Reviewed-by: Michel Dänzer <>
2019-09-23meson: fix builds on Solaris 11.4Alan Coopersmith2-2/+4
Signed-off-by: Alan Coopersmith <>
2019-09-23xf86: Disable unused crtc functions when a lease is revokedAndres Rodriguez1-0/+5
This fixes 'non-desktop' displays staying powered on after their lease has been revoked. Bugzilla: Cc: Keith Packard <> Signed-off-by: Andres Rodriguez <>
2019-09-03modesetting: Disable atomic support by defaultMaarten Lankhorst2-2/+8
The atomic driver has issues with modesetting when stealing connectors from a different crtc, a black screen when doing rotation on a different crtc, and in general is just a mapping of the legacy helpers to atomic. This is already done in the kernel, so just fallback to legacy by default until this is fixed. Please backport to 1.20, as we don't want to enable it for everyone there. It breaks for existing users. The fixes to make the xserver more atomic have been pending on the mailing list for ages. Bugzilla: Bugzilla: References: Signed-off-by: Maarten Lankhorst <>
2019-08-22modesetting: Update props for dynamically added outputsVille Syrjälä1-1/+7
Dynamically added outputs should have their properties properly updated as well. Otherwise we're left with an output with many of its propeties not exposed. Signed-off-by: Ville Syrjälä <> Reviewed-by: Michel Dänzer <>
2019-08-15global: Remove BUILD_DATE and BUILD_TIMEAdam Jackson1-23/+0
All this does is make reproducible builds impossible.
2019-08-09modesetting: Only log 1 error for consecutive flip failuresHans de Goede2-2/+10
Only log 1 error for consecutive flip failures, instead of filling the log and the disk with errors for each attempted flip. Despite our best efforts we may end up with a BO which gets refused when we try to import it as a framebuffer, see e.g. : This should not happen, but as the above bugs shows sometimes it does and chances are it will happen again. Note ideally we should check if the import is possible at ms_present_check_flip time, like the amdgpu code is doing since: but that requires a chunk of refactoring work on the modesetting driver, so for now this will have to do. Reviewed-by: Michel Dänzer <> Signed-off-by: Hans de Goede <>