GitLab

Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

All this work to get there, now enjoy your tear-free desktop!

v2:
 - Rework the manual page to describe the feature and limits better
 - Do not allow TearFree to be enabled if PerCrtcFB is OFF
 - Allow this function to be used even without glamor support

TODO: Make TearFree work without needing to do a modeset

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102508Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

This allows the flip to happen on per-crtc framebuffers.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

This function was really just a way to cast one variable and was used
in a single function, which was itself doing the flush_drm_event on
error.

With this patch, this function is now hiding the nasty loop into it,
to make it easy to re-use. We'll use it in a later patch.

v2:
 - save CPU cycles by using screen->myNum directly (Adam Jackson)
 - allow this function to be used even without glamor
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

This allows us to validate that this codepath is still working
properly, without requiring adding tons of displays and separating
them enough to hit the maximum stride of the display.

v2:
 - Rename from ShadowPrimary to PerCrtcFB (Adam Jackson)
 - Use on/off/auto instead of a boolean (Adam Jackson)
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

This is not giving us tear-free, but we are getting close to it!
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

When the user wants to make his/her screen larger than what the DRM
driver allows, let it happen by using the per-crtc framebuffers and
warn about this in the logs, including about the performance loss.

v2:
 - Demote the warnings from X_ERROR to X_INFO (Adam Jackson)
 - Reword the warnings to better recommend the use of xrender-based
   compositors (Adam Jackson)
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

Suggested-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

This code is currently disabled, but once enabled in future commits,
it will allocate a per-crtc shadow scanout buffer and copy the damages
found in the screen's pixmap.
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

This allows to know what is the damaged part of the screen, in order to
limit the amount of data needing to be blitted to the shadow.

This change also introduces drmmode_update_scanout_buffer() which uses
the damage information to blit the parts that need to be updated.

v2:
 - Uninit the region after doing the intersection (Adam Jackson)
 - Drop the if (pScreen->root) condition as it was useless (Adam
   Jackson & Michel Dänzer)
 - Include gcstruct.h in driver.h when glamor=false to prevent
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

To do so:
 - add a pixmap field to the drmmode_scanout_rec structure
 - split out the pixmap-creation out of drmmode_shadow_create
   into drmmode_scanout_pixmap_create()
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

To do so, introduce a drmmode_scanout_rec structure that contains:
 - the DRM BO
 - the DRM FB id

We then take the generic part of drmmode_shadow_allocate that creates a
scanable buffer and move it to drmmode_scanout_allocate().
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>

The destination is always either on the stack or in the middle of some
struct.
Signed-off-by: Adam Jackson <ajax@redhat.com>

wl_drm's protocol "device" event provides the path to the DRM device,
which may not be a render node, thus causing Xwayland to fall back to
DRM authentication which may fail if the user has switched to another
VT while Xwayland is starting.

Search for a render node corresponding to the given DRM device and try
to use it instead, as render nodes do not need DRM authentication and
Xwayland can make use of them if it can find one.

Closes: https://bugs.freedesktop.org/108038Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

This hasn't done anything besides return TRUE in a long long time.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

These are so close to identical that most DDXes implement one in terms
of the other. All the relevant cases can be distinguished by the error
code, so merge the functions together to make things simpler.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

Mesa started supporting GL_OES_EGL_image on llvmpipe in 17.3, after this
commit:

    commit bbdeddd5fd0b797e1e281f058338b3da4d98029d
    Author: Gurchetan Singh <gurchetansingh@chromium.org>
    Date:   Tue Aug 1 14:49:33 2017 -0700

        st/dri: add drisw image extension

That's pretty cool, but it means glamor now thinks it can initialize on
llvmpipe. This is almost certainly not what anyone wants, as glamor on
llvmpipe is pretty much uniformly slower than fb.

This fixes both Xorg and Xwayland to refuse glamor in such a setup.
Xephyr is left alone, both because glamor is not the default there and
because Xephyr+glamor+llvmpipe is one of the easier ways to get xts to
exercise glamor.

The (very small) downside of this change is that you lose DRI3 support.
This wouldn't have helped you very much (since an lp glamor blit is
slower than a pixman blit), but it would eliminate the PutImage overhead
for llvmpipe's glXSwapBuffers. A future change should add DRI3 support
for the fb-only case.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>

No supported driver supports 1bpp anymore, nor has in a very long time.
This option only worked with vgahw anyway.
Signed-off-by: Adam Jackson <ajax@redhat.com>

Fixes: accd32a4 (xorg: Remove the XF86PM define.)
Signed-off-by: Adam Jackson <ajax@redhat.com>

Inspired by the previous bug, build something we can use to write
damage testcases, including testing for the bug.
Signed-off-by: Eric Anholt <eric@anholt.net>

The mode (CoordModeOrigin or CoordModePrevious) was not taken into
account when computing the box. The result was a bad drawing of
points in some situations (on my hardware/software configuration,
calling XDrawString followed by XDrawPoints in the mode
CoordModePrevious).
Signed-off-by: Cedric Roux <sed@free.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>

So we do not lose subpixel precision in Xwayland.
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: libinput/libinput#138

Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Seems like this was omitted in error
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

v2:
Fix a bogus warning about a missing pixelformat attribute issued for every
pixelformat when WGL_ARB_framebuffer_sRGB isn't available
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Future work: To properly support GLX_ARB_create_context in indirect mode, we
need to use wglCreateContextAttribsARB() rather than wglCreateContext(),
when attribs are provided, rather than just dropping attribs on the floor,
as we currently do.

That probably entails removing the deferred context creation and instead
using a temporary window, as direct WGL does.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

v2:
Set renderType more correctly
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

In glxWinSetPixelFormat() handle the case where wglChoosePixelFormatARB()
fails and fallback to ChoosePixelFormat()

It seems for some drivers, wglChoosePixelFormatARB() can fail when the
provided DC doesn't belong to the driver (e.g. it's a compatible DC for a
bitmap, so allow a fallback to ChoosePixelFormat() if it fails.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

Exposing these pixelFormats is problematic: they are provided by the 'GDI
Generic' renderer, which doesn't support the same set of extensions as the
IGD providing the more capable pixelFormats.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
Reviewed-by: Colin Harrison <colin.harrison@virgin.net>

musl only implements inx/outx on x86, so check for __GLIBC__ instead of
__linux__.
Signed-off-by: Ross Burton <ross.burton@intel.com>

Instead of fetching just the sdkdir variable of xorg-server using pkg-config,
simply get all of the CFLAGS.  Aside from completeness, this helps builds in
sysroots as pkg-config knows what to do with --cflags but doesn't remap
arbitrary variables.
Signed-off-by: Ross Burton <ross.burton@intel.com>

Prodding the builder's filesystem for tmp dirs doesn't necessarily
tell you anything about what the actual host's filesystem is going to
look like, so we should just try the dirs at runtime.
Signed-off-by: Eric Anholt <eric@anholt.net>

Signed-off-by: Eric Anholt <eric@anholt.net>

I don't think this is useful information to have in the log, and it's
a bunch of autotools and meson logic to produce it.
Signed-off-by: Eric Anholt <eric@anholt.net>

Signed-off-by: Eric Anholt <eric@anholt.net>

60ec8ead broke the autotools build:

    sdksyms.o:(.data+0x58): undefined reference to `InitConnectionLimits'
    sdksyms.o:(.data+0x2ec8): undefined reference to `xf86ServerName'
    collect2: error: ld returned 1 exit status
    Makefile:811: recipe for target 'Xorg' failed

Likewise 3a4d7c79 for InitConnectionLimits.
Signed-off-by: Adam Jackson <ajax@redhat.com>

Only the mga XAA code ever set this (hence the compat macro), since XAA
is long gone this can go too.
Signed-off-by: Adam Jackson <ajax@redhat.com>