Emilio Pozuelo Monfort pushed to branch debian-experimental at X Strike Force / 
xserver / xorg-server


Commits:
352a5ac8 by Mario Kleiner at 2018-04-25T14:48:58-04:00
dri3: Fix DRI3.2 support for drivers other than modesetting-ddx.

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: 6e7c40f62db6 ("dri3: Add multi-planar/modifier buffer 
requests")
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Cc: Daniel Stone <dani...@collabora.com>
Cc: Louis-Francis Ratté-Boulianne <l...@collabora.com>
Tested-by: Mike Lothian <m...@fireburn.co.uk>
Reviewed-by: Adam Jackson <a...@redhat.com>

- - - - -
19d006ee by Adam Jackson at 2018-04-25T14:51:02-04:00
dri3: Clamp to 1.0 if not all screens support 1.2

Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Daniel Stone <dani...@collabora.com>

- - - - -
fbc5c5cd by Mario Kleiner at 2018-04-30T13:47:44-04:00
dri3: Fix error handling in dri3_buffer_from_pixmap request.

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: 75bba3aedcb0 ("dri3: Use single-FD screen call for single-FD 
request")
Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
Cc: Daniel Stone <dani...@collabora.com>

- - - - -
55db3c9c by Mario Kleiner at 2018-04-30T13:48:00-04:00
dri3: Robustly clamp to 1.0 if not all screens support 1.2

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 <mario.kleiner...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
Cc: Daniel Stone <dani...@collabora.com>

- - - - -
e00ada9f by Mario Kleiner at 2018-04-30T13:48:46-04:00
glamor: Don't fail in glamor_get_formats if not dmabuf_capable.

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: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>

- - - - -
6cace499 by Louis-Francis Ratté-Boulianne at 2018-04-30T14:01:02-04:00
modesetting: Fix GBM objects leak when checking for flip

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 <l...@collabora.com>

- - - - -
d6f2272f by Adam Jackson at 2018-04-30T14:07:44-04:00
meson: Bump version number here too

Signed-off-by: Adam Jackson <a...@redhat.com>

- - - - -
975d3a50 by Adam Jackson at 2018-04-30T15:49:44-04:00
xwayland: Avoid using epoxy_has_egl()

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: Adam Jackson <a...@redhat.com>
Reviewed-by: Mario Kleiner <mario.kleiner...@gmail.com>

- - - - -
a843c614 by Roman Gilg at 2018-04-30T15:52:16-04:00
xwayland: restrict present cleanup to presenting and top parent window

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: Adam Jackson <a...@redhat.com>
Signed-off-by: Roman Gilg <subd...@gmail.com>

- - - - -
d7297b00 by Chris Wilson at 2018-05-02T12:20:01-04:00
randr: Account for panning and transforms when constraining the cursor

commit 56c90e29f04727c903bd0f084d23bf44eb1a0a11 [1.10.99.901]
Author: Adam Jackson <a...@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 1bf81af4a6be1113bcc3b940ab264d5c9e0f0c5d [1.12.99.904]
Author: Rui Matos <tiagoma...@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 <ch...@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39949
Reviewed-by: Adam Jackson <a...@redhat.com>
Cc: Rui Matos <tiagoma...@gmail.com>

- - - - -
22285a6f by Roman Gilg at 2018-05-02T14:55:48-04:00
present: fix msc offset calculation in window mode

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: Roman Gilg <subd...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>

- - - - -
531e1648 by Adam Jackson at 2018-05-02T15:00:53-04:00
gitlab-ci: Add for gitlab.freedesktop.org

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 <a...@redhat.com>

- - - - -
4191b59b by Adam Jackson at 2018-05-02T15:10:20-04:00
meson: Fix build with three-component version numbers

Otherwise:

include/meson.build:5:0: ERROR: Index 3 out of bounds of array of size 3.

Signed-off-by: Adam Jackson <a...@redhat.com>

- - - - -
1dcd784a by Anuj Phogat at 2018-05-07T12:18:28-04:00
dri2: Sync i965_pci_ids.h from mesa

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 <kenn...@whitecape.org>
Signed-off-by: Anuj Phogat <anuj.pho...@gmail.com>

- - - - -
1a3e4a2f by Aaron Plattner at 2018-05-07T12:23:34-04:00
meson: Define DEFAULT_LIBRARY_PATH as join_paths(get_option('prefix'), 
get_option('libdir'))

'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 <aplatt...@nvidia.com>
Reviewed-by: Thierry Reding <tred...@nvidia.com>

- - - - -
f5ded22e by Aaron Plattner at 2018-05-07T12:25:00-04:00
meson: Set XCONFIGFILE to 'xorg.conf' instead of 
'/etc/xorg.conf'

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: Aaron Plattner <aplatt...@nvidia.com>
Reviewed-by: Thierry Reding <tred...@nvidia.com>

- - - - -
73f0ed2d by Mario Kleiner at 2018-05-07T12:32:40-04:00
modesetting: Remove ms_crtc_msc_to_kernel_msc().

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 <mario.kleiner...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>
Cc: Keith Packard <kei...@keithp.com>
Tested-by: Mike Lothian <m...@fireburn.co.uk>

- - - - -
c9afd8cb by Mario Kleiner at 2018-05-07T14:01:01-04:00
modesetting: Fix and improve ms_kernel_msc_to_crtc_msc()

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: Mario Kleiner <mario.kleiner...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>
Cc: Keith Packard <kei...@keithp.com>
Cc: Michel Dänzer <michel.daen...@amd.com>

- - - - -
cf838f5c by Roman Gilg at 2018-05-07T15:24:23-04:00
xwayland: persistent window struct on present

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: Roman Gilg <subd...@gmail.com>
Tested-by: Olivier Fourdan <ofour...@redhat.com>

- - - - -
e1ccd0fa by Eric Anholt at 2018-05-08T11:59:28-04:00
dix: Fix a warning about GetTimeInMillis return value in XFont2.

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

- - - - -
4ec02b57 by Eric Anholt at 2018-05-08T11:59:31-04:00
randr: Fix a compiler warning on 32-bit.

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

- - - - -
5e86484a by Eric Anholt at 2018-05-08T11:59:34-04:00
dri3: Switch get_drawable_modifiers to using stdint.

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: Eric Anholt <e...@anholt.net>
Reviewed-by: Adam Jackson <a...@redhat.com>

- - - - -
4c754b01 by Eric Anholt at 2018-05-08T11:59:36-04:00
dri3: Switch get_modifiers to using stdint.

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: Adam Jackson <a...@redhat.com>

- - - - -
ef953316 by Eric Anholt at 2018-05-08T11:59:41-04:00
dri3: Switch fds_from_pixmap to stdint types.

Again, this was causing 32-bit build warnings due to mixing CARD* and
stdint.

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

- - - - -
b23a0e4d by Eric Anholt at 2018-05-08T11:59:44-04:00
xwayland: Fix a 32-bit build warning.

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

- - - - -
cc66777d by Adam Jackson at 2018-05-08T12:15:29-04:00
xwayland: Don't create a "fake" crtc for Present

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 <a...@redhat.com>
Tested-by: Roman Gilg <subd...@gmail.com>
Reviewed-by: Roman Gilg <subd...@gmail.com>

- - - - -
b9f415cb by Adam Jackson at 2018-05-08T12:15:29-04:00
present: Fix swapping of PresentCompleteNotify events

The code would fall through to the PresentIdleNotify case, and nothing
good would come of it.

Signed-off-by: Adam Jackson <a...@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersm...@oracle.com>

- - - - -
9f21872a by Adam Jackson at 2018-05-08T12:15:30-04:00
glx: Be sure to set an error for ghost contexts

Otherwise the caller is going to return garbage memory for the error
value.

Signed-off-by: Adam Jackson <a...@redhat.com>

- - - - -
0445705a by Adam Jackson at 2018-05-08T12:15:30-04:00
man: Fix automake seddery

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: Adam Jackson <a...@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersm...@oracle.com>

- - - - -
9d628ee5 by Roman Gilg at 2018-05-08T12:41:58-04:00
modesetting: set gbm as dependency in meson build

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: Roman Gilg <subd...@gmail.com>
Reviewed-by: Adam Jackson <a...@redhat.com>

- - - - -
b6bf68b8 by Aaron Plattner at 2018-05-09T13:36:25-04:00
meson: Fix module_dir configuration (v2)

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: Aaron Plattner <aplatt...@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

- - - - -
82f8fc5f by Adam Jackson at 2018-05-10T12:24:11-04:00
xserver 1.20

Signed-off-by: Adam Jackson <a...@redhat.com>

- - - - -
4cd77b29 by Emilio Pozuelo Monfort at 2018-05-19T13:21:48+02:00
Merge branch 'upstream-experimental' into debian-experimental

- - - - -
f4e9f866 by Emilio Pozuelo Monfort at 2018-05-19T13:22:41+02:00
New upstream stable release

- - - - -
20159320 by Emilio Pozuelo Monfort at 2018-05-19T13:23:42+02:00
Update Vcs-* for salsa

- - - - -
ca2c91d3 by Emilio Pozuelo Monfort at 2018-05-19T15:04:13+02:00
Release to experimental

- - - - -


30 changed files:

- + .gitlab-ci.yml
- configure.ac
- debian/changelog
- debian/control
- dix/dixfonts.c
- dri3/dri3.h
- dri3/dri3_priv.h
- dri3/dri3_request.c
- dri3/dri3_screen.c
- glamor/glamor.c
- glamor/glamor.h
- glamor/glamor_egl.c
- glx/glxcmds.c
- hw/xfree86/dri2/pci_ids/i965_pci_ids.h
- hw/xfree86/drivers/modesetting/driver.h
- hw/xfree86/drivers/modesetting/drmmode_display.h
- hw/xfree86/drivers/modesetting/meson.build
- hw/xfree86/drivers/modesetting/present.c
- hw/xfree86/drivers/modesetting/vblank.c
- hw/xwayland/xwayland-glamor-gbm.c
- hw/xwayland/xwayland-glamor.c
- hw/xwayland/xwayland-present.c
- hw/xwayland/xwayland.c
- hw/xwayland/xwayland.h
- include/meson.build
- manpages.am
- meson.build
- meson_options.txt
- present/present_event.c
- present/present_wnmd.c


The diff was not included because it is too large.


View it on GitLab: 
https://salsa.debian.org/xorg-team/xserver/xorg-server/compare/c6e784fb4fb6d10adff7226747273796162c8808...ca2c91d3a05013425594d04faf53e3f103f7071d

---
View it on GitLab: 
https://salsa.debian.org/xorg-team/xserver/xorg-server/compare/c6e784fb4fb6d10adff7226747273796162c8808...ca2c91d3a05013425594d04faf53e3f103f7071d
You're receiving this email because of your account on salsa.debian.org.

Reply via email to