Commits on Source (36)
-
Mario Kleiner authored
Both xf86-video-intel and xf86-video-nouveau cause OpenGL clients to fail when used with DRI3 on server 1.20 with Mesa 18.1. Reason is that the servers DRI3 version is now unconditionally reported as DRI3 1.2 to 1.2 capable clients. This causes clients using Mesa 18.1 to use the new DRI 3.2 requests DRI3GetSupportedModifiers, DRI3PixmapFromBuffers, etc. Drivers other than modesetting-ddx do not support the needed hooks like info->pixmap_from_fds or info->get_formats, info->get_modifiers. Unfortunately we can't simply report the servers DRI3 version as 1.0 in this case, as the reported version can not be specific to a X-Screen, and different screens may have drivers with different capabilities. Luckily the server has fallbacks to ->pixmap_from_fd, ->fd_from_pixmap, and simply reporting an empty set of supported modifiers for the DRI3GetSupportedModifiers request if the ddx doesn't support DRI 3.2. Clients like Mesa 18.1's dri3 loader respond to the empty set of reported modifiers by falling back to a dri driver selected buffer format (image->createImageWithModifiers responds to a NULL modifier_list by acting like ->createImage()). This works, but Mesa 18.1 will still try to use the DRI3PixmapFromBuffers request to create the corresponding pixmap, just passing in a modifier that corresponds to whatever tiling the dri driver selected by default. To prevent this request - and thereby the client - from failing with a BadImplementation error, remove the check for modifier == DRM_MOD_FORMAT_INVALID in the pixmap_from_fd fallback path of dri3_pixmap_from_fds() and trust that if we hit the fallback path then the client will have passed a buffer with some driver specific default tiling that can be handled by pixmap_from_fd. Another approach would be for Mesa's dri3 loader to keep track how a buffer was created (with explicit modifiers or not), and then call DRI3PixmapFromBuffers or DRI3PixmapFromBuffer, but then any future DRI3 client implementation would need to be fixed, so the server side is probably the better place for this. Tested on Intel Ivybridge and NVidia Pascal. Fixes: 6e7c40f6 ("dri3: Add multi-planar/modifier buffer requests") Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Louis-Francis Ratté-Boulianne <lfrb@collabora.com> Tested-by:
Mike Lothian <mike@fireburn.co.uk> Reviewed-by:
Adam Jackson <ajax@redhat.com>
-
Adam Jackson authored
Signed-off-by:
Daniel Stone <daniels@collabora.com>
-
Mario Kleiner authored
The old info->fd_from_pixmap() driver hook, which is preferentially used in dri3_fd_from_pixmap(), can return error codes other than -1, e.g., -EINVAL (-22) on nouveau-ddx. Not handling the error causes a broken/corrupted X-Connection resulting from a failed request. This fixes failure of sddm-greeter to start up under nouveau-ddx with DRI3 enabled and DRI3 protocol version properly clamped to 1.0 by the server (see followup patch). Fixes: 75bba3ae ("dri3: Use single-FD screen call for single-FD request") Signed-off-by:
-
Mario Kleiner authored
Checking for dri3_screen_info_rec.version >= 2 is insufficient, as some shipping drivers, e.g., intel-ddx, nouveau-ddx, set the version to DRI3_SCREEN_INFO_VERSION, ie. to whatever version the installed servers headers define. On server 1.20 that would be version 2, but the drivers still don't support the v1.2 hooks. Make sure all hooks are defined before reporting v1.2. Also make clamping of reported version to minimum of client or server robust against possible future clients with possible majorVersion >= 2.0. Signed-off-by:
-
Mario Kleiner authored
If dmabuf_capable is false, because the server "dmabuf_capable" debug flag isn't set, treat it as successfull query with zero returned formats, instead of failure. This allows the servers cache_formats_and_modifiers() function to cache the fact that formats are not supported during the current server generation, instead of pointless retesting at every invocation. Signed-off-by:
-
Louis-Francis Ratté-Boulianne authored
GBM objects were never destroyed after looking for format and modifier compatibility when deciding whether flipping or copying a presented pixmap. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106106 Signed-off-by:
Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
-
Adam Jackson authored
Signed-off-by: -
Adam Jackson authored
There's no real point - if we don't have EGL then the extension check is also going to fail - and the entrypoint is new in 1.5.0, which we don't need to require yet. Signed-off-by:
-
Roman Gilg authored
Clean up only if the request points to the presenting window or its top parent window. Since in this case all events are removed unconditionally, always stop the timer. Reviewed-by:
Roman Gilg <subdiff@gmail.com>
-
Chris Wilson authored
commit 56c90e29 [1.10.99.901] Author: Adam Jackson <ajax@redhat.com> Date: Mon Nov 15 14:29:14 2010 -0500 randr: Add RRConstrainCursorHarder introduced a regression as it ignored the effect of panning and transforms upon the crtc bounds. The result was that the cursor would be constrained to the visible area even though the panning arena was much bigger, or the cursor was constrained to a region that did not even match the visible area when the output was transformed or reflected. This supercedes the hack introduced by commit 1bf81af4 [1.12.99.904] Author: Rui Matos <tiagomatos@gmail.com> Date: Mon Jul 30 14:32:12 2012 -0400 xf86RandR12: Don't call ConstrainCursorHarder() if panning is enabled which disabled the cursor constraints if a panning mode was active, but did not fix the regression with arbitrary output transforms. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39949 Reviewed-by:
-
Roman Gilg authored
Instead of getting the current msc value from the window, which might be different to old one directly take the last saved msc value saved in the window_priv struct. Signed-off-by:
-
Adam Jackson authored
Looks quite a bit like the travis path, doesn't it? Still, nice to not rely on an external service if we don't have to. Signed-off-by: -
Adam Jackson authored
Otherwise: include/meson.build:5:0: ERROR: Index 3 out of bounds of array of size 3. Signed-off-by: -
Anuj Phogat authored
Copied from Mesa with no modifications. Gives us Cofeelake platform names updates and sync on Kaby Lake, Ice Lake PCI IDs. Acked-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Anuj Phogat <anuj.phogat@gmail.com>
-
Aaron Plattner authored
'libdir' defaults to 'lib', so running X -showDefaultLibPath just prints 'lib' instead of '/usr/lib' or '/usr/local/lib'. Use joint_paths() to get the correct full path. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Reviewed-by:
Thierry Reding <treding@nvidia.com>
-
Aaron Plattner authored
The autoconf build hard-codes XCONFIGFILE to just 'xorg.conf': XF86CONFIGFILE="xorg.conf" AC_DEFINE_DIR(XCONFIGFILE, XF86CONFIGFILE, [Name of configuration file]) Later, the X server passes that into DoSubstitution() which expands the path: DoSubstitution(template="/etc/X11/%X", ..., XConfigFile="xorg.conf") This returns "/etc/X11/xorg.conf". The Meson build, on the other hand, sets XCONFIGFILE to join_paths(get_option('sysconfdir'), 'xorg.conf'). If sysconfdir is /etc, this results in '/etc/xorg.conf', resulting in DoSubstitution returning '/etc/X11/etc/xorg.conf'. Fix this by just hard-coding XCONFIGFILE to 'xorg.conf'. Signed-off-by: -
Mario Kleiner authored
The function is ported from intel-ddx uxa backend around 2013, where its stated purpose was to apply a vblank_offset to msc values to correct for problems with those kernel provided msc values. Some (somewhat magic and puzzling to myself) heuristic tried to guess if provided values were unreasonable and tried to adapt the corrective vblank_offset to account for that. Except: It wasn't applied to kernel provided msc values, but the values delivered by clients via DRI2 or Present, so valid client targetmsc values, e.g., requesting a vblank event > 1000 vblanks in the future, triggered the offset correction in arbitrarily wrong ways, leading to wrong msc values being returned and thereby vblank events queued to the kernel for the wrong time. This causes glXSwapBuffersMscOML and glXWaitForMscOML to swap / return immediately whenever a swap/wait in > 1000 vblanks is requested. The original code was also written to only deal with 32 bit mscs, but server 1.20 modesetting ddx can now use new Linux 4.15+ kernel vblank api to process true 64 bit msc's, which may confuse the heuristic even more due to 32 bit integer truncation/wrapping. This code caused various problems in the intel-ddx in the past since year 2013, and was removed there in 2015 by Chris Wilson in commit 42ebe2ef9646be5c4586868cf332b4cd79bb4618: " uxa: Remove the filtering of bogus Present MSC values If the intention was to filter the return values from the kernel, the filtering would have been applied to the kernel values and not to the incoming values from Present. This filtering introduces crazy integer promotion and truncation bugs all because Present feeds garbage into its vblank requests. " Indeed, i found a Mesa bug yesterday which can cause Mesa's PresentPixmap request to spuriously feed garbage targetMSC's into the driver under some conditions. However, while other video drivers seem to cope relatively well with that, modesetting ddx causes KDE-5's plasmashell to lock up badly quite frequently, and my suspicion is that the code removed in this commit is one major source of the extra fragility. Also my own tests fail for any swap scheduled more than 1000 vblanks into the future, which is not uncommon for some scientific applications. Iow. modesetting's swap scheduling seems to be more robust without this function afaics. Signed-off-by: -
Mario Kleiner authored
The old 32-Bit wraparound handling didn't actually work, due to some integer casting bug, and the mapping was ill equipped to deal with input from the new true 64-bit GetCrtcSequence/QueueCrtcSequence api's introduced in Linux 4.15. For 32-Bit truncated input from pageflip events and old vblank events and old drmWaitVblank ioctl, implement new wraparound handling, which also allows to deal with wraparound in the other direction, e.g., if a 32-Bit truncated sequence value is passed in, whose true 64-Bit in-kernel hw value is within 2^30 counts of the previous processed value, but whose 32-bit truncated sequence value happens to lie just above or below a 2^32 boundary, iow. one of the two values 'sequence' vs. 'msc_prev' lies above a 2^32 border, the other one below it. The method is directly translated from Mesa's proven implementation of the INTEL_swap_events extension, where a true underlying 64-Bit wide swapbuffers count (SBC) needs to get reconstructed from a 32-Bit LSB truncated SBC transported over the X11 protocol wire. Same conditions apply, ie. successive true 64-Bit SBC values are close to each other, but don't always get received in strictly monotonically increasing order. See Mesa commit cc5ddd584d17abd422ae4d8e83805969485740d9 ("glx: Handle out-of-sequence swap completion events correctly. (v2)") for explanation. Additionally add a separate path for true 64-bit msc input originating from Linux 4.15+ drmCrtcGetSequence/QueueSequence ioctl's and corresponding 64-bit vblank events. True 64-bit msc's don't need remapping and must be passed through. As a reliability bonus, they are also used here to update the tracking values msc_prev and ms_high with perfect 64-Bit ground truth as baseline for mapping msc from pageflip completion events, because pageflip events are always 32-bit wide, even when the new kernel api's are used. Because each pageflip(-event) is always preceeded close in time (and vblank count) by a drmCrtcQueueSequence queued event or drmCrtcGetSequence query as part of DRI2 or DRI3+Present swap scheduling, we can be certain that each pageflip event will get its truncated 32-bit msc remapped reliably to the true 64-bit msc of flip completion whenever the sequence api is available, ie. on Linux 4.15 or later. Note: In principle at least the 32-bit mapping path could also be backported to earlier server branches, as this seems to be broken for at least server 1.16 to 1.19. Signed-off-by: -
Roman Gilg authored
Instead of reusing xwl_window introduce a persistent window struct for every window, that asks for Present flips. This struct saves all relevant data and is only freed on window destroy. Signed-off-by:
Olivier Fourdan <ofourdan@redhat.com>
-
Emma Anholt authored
Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Emma Anholt authored
Signed-off-by:
-
Emma Anholt authored
We were mixing stdint and CARD* types, causing compiler warnings on 32-bit. Just switch over to stdint, which is what we'd like the server to be using long term, anyway. Signed-off-by:
-
Emma Anholt authored
We were mixing stdint and CARD* types, causing compiler warnings on 32-bit. Just switch over to stdint, which is what we'd like the server to be using long term, anyway. Reviewed-by: -
Emma Anholt authored
Again, this was causing 32-bit build warnings due to mixing CARD* and stdint. Signed-off-by:
-
Emma Anholt authored
Signed-off-by:
-
Adam Jackson authored
We probably don't want a fake crtc to be visible to clients, and we definitely don't want to generate events every time we create such a fake (which would happen as a side effect from RRCrtcCreate hitting RRTellChanged). As it happens we're not actually using that crtc for anything because xwayland doesn't store any state on the crtc object, so it suffices to use the real crtc for the screen. Signed-off-by:
-
Adam Jackson authored
The code would fall through to the PresentIdleNotify case, and nothing good would come of it. Signed-off-by:
Alan Coopersmith <alan.coopersmith@oracle.com>
-
Adam Jackson authored
Otherwise the caller is going to return garbage memory for the error value. Signed-off-by: -
Adam Jackson authored
Because this is an automakefile, things inside @@ get expanded, which means your sed ends up saying s|/var/log|/var/log| and your manual pages still have @logdir@ in them. Fix this by hiding the @s inside a trivial character range, which keeps the pattern preserved all the way into the Makefile. Signed-off-by:
-
Roman Gilg authored
Modifiers support needs gbm as a dependency. Without setting the dependency included headers are not found reliably and the build might fail if the headers are not placed in the default system include paths. Signed-off-by:
-
Aaron Plattner authored
meson.build has code to set the module_dir variable to ${libdir}/xorg/modules if the module_dir option string is empty. However, this has several problems: 1. The variable is only used for an unused @moduledir@ substitution in the man page. The rule for xorg-server.pc uses option('module_dir') directly instead. 2. The 'module_dir' option has a default value of 'xorg/modules' so the above rule doesn't do anything by default. 3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so the effect of #2 is that the default moduledir is different between autoconf and meson. E.g. if ${prefix} is /X, then you get autoconf: moduledir=/X/lib/xorg/modules meson: moduledir=/X/xorg/modules Fix this by using the module_dir variable when generating xorg-server.pc, and by using join_paths() to assign module_dir unconditionally. v2: Keep the 'xorg/modules' default path, but use join_paths() unconditionally (Thierry Reding) Signed-off-by:Peter Hutterer <peter.hutterer@who-t.net>
-
Adam Jackson authored
Signed-off-by: -
Emilio Pozuelo Monfort authored
-
Emilio Pozuelo Monfort authored
-
Emilio Pozuelo Monfort authored
-
Emilio Pozuelo Monfort authored
.gitlab-ci.yml
0 → 100644