Merge xorg server git latest #8
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This restricts an optimization whereby the filling of 1x1 pixmaps went around the driver-provided function to cases where the source color is meant to be directly copied to the destination, as opposed to other operations which should produce different destination values than just the foreground color. Signed-off-by: George Matsumura <gmmatsumura01@bvsd.org> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
* GCC 10 will switch the default to `-fno-common`. https://gcc.gnu.org/PR85678 Bug: https://bugs.gentoo.org/705880 Signed-off-by: Matt Turner <mattst88@gmail.com>
It's true that the value would always be -1, if it's not zero, but it's usually zero is the problem. As a result we return failure from otherwise successful indirect GLX paths, which isn't very nice of us. This reverts commit 7d33ab0. Fixes: https://gitlab.freedesktop.org/xorg/xserver/issues/211
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";
| ^
xcb_aux_parse_color takes a non-const pointer, even though it doesn't
modify the string or take ownership of its memory.
Avoids the following warning from GCC:
../hw/kdrive/ephyr/hostx.c: In function ‘hostx_init’:
../hw/kdrive/ephyr/hostx.c:683:30: warning: passing argument 1 of ‘xcb_aux_parse_color’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
683 | if (!xcb_aux_parse_color("red", &red, &green, &blue)) {
| ^~~~~
In file included from ../hw/kdrive/ephyr/hostx.c:50:
/usr/include/xcb/xcb_aux.h:194:27: note: expected ‘char *’ but argument is of type ‘const char *’
194 | xcb_aux_parse_color(char *color_name,
| ~~~~~~^~~~~~~~~~
GCC warned about it:
../test/misc.c:36:19: warning: redundant redeclaration of ‘screenInfo’ [-Wredundant-decls]
36 | extern ScreenInfo screenInfo;
| ^~~~~~~~~~
In file included from ../test/misc.c:30:
../include/scrnintstr.h:688:29: note: previous declaration of ‘screenInfo’ was here
688 | extern _X_EXPORT ScreenInfo screenInfo;
| ^~~~~~~~~~
There are no warnings left, so let's prevent new ones from creeping back in.
You might as well, it's harmless. Better, some cleanup code (like DRI2 swap wait) needs to run both normally and at client exit, so it simplifies the callers to not need to check first. See 4308f5d for a similar example. Props: @Ajax (Adam Jackson) Fixes: xorg/xserver#211 Signed-off-by: Daniel Llewellyn <diddledan@ubuntu.com>
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: https://gitlab.freedesktop.org/xorg/xserver/issues/969 Fixes: 094f42c "xfree86/modes: Call xf86RotateRedisplay from xf86CrtcRotate" Acked-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
It flushes any pending drawing to the kernel, to make sure it'll be visible to the Wayland server. Without this, it was possible for the Wayland server to process surface commits before Xwayland got around to flushing the corresponding drawing, which could result in stale or even completely random window contents being visible. v2: * Make EGL backend post_damage hook mandatory, don't check for NULL in xwl_glamor_post_damage. (Olivier Fourdan) Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/951 Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
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: 9257b12 ("modesetting: add dynamic connector hotplug support (MST) (v3)") Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* This prevents issues from creeping back in at a later stage.
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 xorg/xserver#910. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/909 Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Fixes: cb1b1e1 "modesetting: Indirect the glamor API through LoaderSymbol" Reviewed-by: Adam Jackson <ajax@redhat.com>
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: c66c548 "modesetting: Call glamor_finish from
drmmode_crtc_set_mode"
Reviewed-by: Adam Jackson <ajax@redhat.com>
It's long and kind of redundant. Reviewed-by: Adam Jackson <ajax@redhat.com>
To prevent breakage with glamor disabled from creeping in again. Reviewed-by: Adam Jackson <ajax@redhat.com>
This reverts commit 9e85aa9. To be replaced with a better solution. Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
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.
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>
Xorg supports the '-version' command line option, add something similar to Xwayland. Closes: https://gitlab.freedesktop.org/xorg/xserver/issues/976 Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Jonas Ådahl <jadahl@gmail.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
We can use value arguments instead of pointers when adjusting the timings by returning the adjusted value. This improves the readability. Signed-off-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Unfold and extensively annotate the target-msc adjustment function, to make it easier to understand what's happening and why. Signed-off-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Make the code more readable by going through some logical abort conditions. Also make the function only about updating the crtc msc value and not about also returning the next target msc. Signed-off-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Move the code portion down. That way it is at a similar position as in the window mode file. Signed-off-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The value is not the current msc of the window, but the target value the client sets independently of the window speicific msc offset. Make this clearer. Signed-off-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Instead of iterating over all clients which are listening for events on the root window and checking if the client we are dealing with is the one listening for SubstructureRedirectMask | ResizeRedirectMask events and thus is the window-manager, cache the client-id of the window-manager in xwl_screen and use that when checking if a client is the window-manager. Note that we cache and compare the client-id rather then the ClienPtr, this saves reading the ClientPtr from the global clients array when doing the comparison. Suggested-by: Olivier Fourdan <ofourdan@redhat.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
When a viewport is already created we can reuse this object instead of destroying it and getting a new one for updating the source rectangle and destination size. Signed-off-by: Roman Gilg <subdiff@gmail.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Olivier Fourdan <ofourdan@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
All of these uses were attempting to set FD_CLOEXEC, which happens to be (1<<0). Since flags is going to be aligned in memory, its address is never going to have the low bit set, so we were never actually setting what we meant to. Fixes: xorg/xserver#1114
Pointer-emulated touch events should only be delivered to the client that owns the sequence even if it's a core client that became the effective owner of the sequency by selecting for pointer press and movement. Currently the emulated events are delivered like this already (see TouchResourceIsOwner() check in DeliverEmulatedMotionEvent()), except in the case of TouchEnd, in which case the generated motion event is still delivered to some client that's not necessarily the owner of the touch sequence. We already know whether a touch sequence that is about to emulate a pointer event has an owner, we just need to check that. This further allows to simplify DeliverEmulatedMotionEvent() as it won't ever be called for non-owned touch events. https://bugs.freedesktop.org/show_bug.cgi?id=60394 Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
There are currently no callers that make use of the "created" output parameter of xwl_glamor_pixmap_get_wl_buffer. Remove it, along with the corresponding argument of the associated EGL backend entrypoint.
Since commit b3f3d65, xwayland now supports the command line option "-listenfd" for passing file descriptors and marked "-listen" as deprecated for this specific purpose. Add a new pkg-config variable "have_listenfd" to the xwayland.pc so that compositors can know this is available and use listenfd in place of the deprecated option. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
This is a requirement for testing meson dist in CI.
While this isn't critical yet, it might become so at some point, so let's make sure it keeps working. Don't set the PIGLIT/XTEST_DIR variables for ninja dist, testing XTS once against each DDX is enough (as part of ninja test). Requires git in the docker image. v2: * Drop /usr/local/bin/xkbcomp symlink, no longer needed with xkbcomp 1.4.1 (Peter Hutterer)
The definition relies on IOPortBase, which is only ever set in hw/xfree86/os-support/bsd/arm_video.c This caused build failures on linux/mips with GCC 10, due to this change (from https://gcc.gnu.org/gcc-10/changes.html#c): "GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking." As a result anything including compiler.h would get its own definition of IOPortBase and the linker would error out.
Makes it easier to debug Xwayland problems. Signed-off-by: Misha Gusarov <dottedmag@dottedmag.net>
When enabling or disabling an extension which is not known to the Xserver, it will log an error message and list the extensions it knows about. That clutters the logs when the Xserver is Xwayland spawned by the Wayland compositor who doesn't actually know the list of extensions enabled at build time in the Xserver. Considering that disabling a non-existing extension is a no-op anyway, list all the extensions available only when attempting to enable an extension which the Xserver doesn't know about. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Not all extensions can be enabled or disabled at runtime, list the extensions which can from the help message rather than on error only. v2: * Print the header message in the ListStaticExtensions() (Peter Hutterer) * Do not export ListStaticExtensions() as Xserver API Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
This reverts commit f665a9c. Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Acked-by: Martin Peres <martin.peres@mupuf.org> Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1108 Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1128
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
…nowLeopard Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
…ources Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Fixes: XQuartz/XQuartz#30 Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
When an X11 client issues an active grab on the keyboard, Xwayland forward this to the Wayland compositor using the Xwayland specific protocol "xwayland-keyboard-grab" if it can find the corresponding Xwayland window. Some X11 clients (typically older games) however try to issue the keyboard grab on the X11 root window, which has obviously no matching Xwayland window. In such a case, the grab is simply ignored and the game will not work as expected. To workaround that issue, if an X11 client issues a keyboard grab on the root window, Xwayland will search for a toplevel window belonging to the same X11 client that it can use as the grab window instead. This way, the grab can be forwarded to the Wayland compositor that can either grant or deny the request based on the window and its internal policies. The heuristic picks the first realized toplevel window belonging to the client so that the Wayland compositor will send it the keyboard events, and the Xserver grab mechanism will then take care of routing the events to the expected X11 window by itself. v2: Make the test more clear (Dor Askayo <dor.askayo@gmail.com>) Signed-off-by: Olivier Fourdan <ofourdan@redhat.com> Acked-by: Jonas Ådahl <jadahl@gmail.com> See-also: https://gitlab.gnome.org/GNOME/mutter/-/issues/1249
Author
|
New PR - obsoletes Sorry, but I deleted the old github fork, so I could not update the old PR :-( |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updating xserver-ogon to latest xserver-xorg git version.