The module directory has changed to a per ABI folder in the xlibre-xserver.
Now the default value of `xorg-module-dir` will be detected from the `moduledir` variable in xorg-server.pc.
Signed-off-by: b-aaz <b-aazbsd.proton.me>
This pipeline builds the driver against the latest Xserver stable
release as well as current master.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function radeon_cs_flus_indirect() attempts to flush radeon
operations, which have already been flushed by glamor_close_screen().
This results in a segfault.
Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
In the function radeon_glamor_destroy_pixmap a check
if (screen->DestroyPixmap(pixmap)) was erroneously used instead of
if (screen->DestroyPixmap), which resulted in destroying a pixmap
twice and hence in a segfault.
Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
Add the following forms for issue creation:
* Bug report
* Feature request
* Code change
* Documentation update
* Organizational task
* add issue type selection page on "New Issue" call
* mention Github Discussions and the mailing list where appropriate
Part-of: X11Libre/misc#156
Signed-off-by: callmetango <callmetango@users.noreply.github.com>
xorg-server includes its own bswap_16, bswap_32 etc macros in
its misc.h. This is transcluded after radeon.h in some files.
If the operating system defines bswap_XX in a way that is
unsuitable for a function name (e.g. on NetBSD), this results
in build failures.
Signed-off-by: Nia Alarie <nia@NetBSD.org>
Part-of: <https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/merge_requests/23>
Prior to commit 18d5ae3bd9
gb_tile_config was used in OUTREG(R300_GB_TILE_CONFIG, gb_tile_config);
but since then it's unused, and is flagged by recent clang versions:
radeon_accel.c:209:14: error: variable 'gb_tile_config' set but not used
[-Werror,-Wunused-but-set-variable]
uint32_t gb_tile_config, vap_cntl;
^
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/merge_requests/19>
inspired from similar code in amdgpu, fixes a crash when xrandr(1)
is invoqued with X server 21.1.1
Signed-off-by: Matthieu Herrb <matthieu.herrb@laas.fr>
Based on xf86-video-amdgpu, but applying experience gained in the
meantime in other projects and taking advantage of new features
available with current versions of GitLab.
Fixes compile errors with glamor disabled:
../../src/radeon_present.c: In function ‘radeon_present_check_flip’:
../../src/radeon_present.c:281:21: error: invalid use of undefined type ‘struct radeon_pixmap’
281 | if (priv && priv->fb_failed)
| ^~
../../src/radeon_present.c:288:19: error: invalid use of undefined type ‘struct radeon_pixmap’
288 | if (priv && !priv->fb_failed) {
| ^~
../../src/radeon_present.c:292:10: error: invalid use of undefined type ‘struct radeon_pixmap’
292 | priv->fb_failed = TRUE;
| ^~
When the drmModeSetCursor2() call was replaced with bare drmIoctl() call in
92df7097, a bug was introduced. With the use of drmModeSetCursor2(),
the return value from drmIoctl() (which calls ioctl()) were mangled, if
they were negative, they were replaced by -errno by a wrapper function
in xf86drMode.c in libdrm. After replacing drmModeSetCursor2() with the
call to drmIoctl(), this mangling no longer happens, and we need to
explicitly check if the call to drmIoctl() fails, which is indicated by
returning -1, and then why it failed, by checking errno.
If the error indicated by errno is EINVAL, then we can't use the
DRM_IOCTL_MODE_CURSOR2 ioctl(), and need to fall back to the
DRM_IOCTL_MODE_CURSOR ioctl().
This bug can manifest itself by an invisible hw cursor on systems where the
DRM_IOCTL_MODE_CURSOR2 is not implemented by the graphics driver.
Credit also to Alexey Dokuchaev for help with developing the fix and
testing.
This fixes#190
Signed-off-by: Niclas Zeising <zeising@daemonic.se>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Commit d1d8e3c8d0 causes X server
to fail on startup when GPU acceleration is not working (or is
disabled). The reason is that `radeon_get_pixmap_bo` function
gets called too early (before EXA has been initialized) and
fails with an assert:
#0 __GI_raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x76ab1c6c in __GI_abort () at abort.c:79
#2 0x76ac0b64 in __assert_fail_base (fmt=0x76bfbce4 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7658c80c "key->initialized", file=<optimized out>, line=121,
function=0x7658d040 <__PRETTY_FUNCTION__.10607> "dixGetPrivateAddr") at assert.c:92
#3 0x76ac0c0c in __GI___assert_fail (assertion=0x7658c80c "key->initialized", file=0x7658c9d0 "../include/privates.h", line=121,
function=0x7658d040 <__PRETTY_FUNCTION__.10607> "dixGetPrivateAddr") at assert.c:101
#4 0x76579e6c in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=<optimized out>) at ../include/privates.h:121
#5 0x7657a954 in dixGetPrivateAddr (key=<optimized out>, key=<optimized out>, privates=<optimized out>) at exa.c:70
#6 dixGetPrivate (key=<optimized out>, privates=<optimized out>) at ../include/privates.h:136
#7 exaGetPixmapDriverPrivate (pPix=<optimized out>) at exa.c:68
#8 0x7623d460 in radeon_get_pixmap_bo (pPix=0x71c1b8) at radeon.h:804
#9 radeon_get_pixmap_handle (pixmap=0x71c1b8, handle=0x7fa22328) at radeon_bo_helper.c:357
#10 0x76244458 in radeon_pixmap_get_fb (pix=0x71c1b8) at radeon.h:886
#11 drmmode_set_mode_major (crtc=0x691860, mode=0x69191c, rotation=<optimized out>, x=<optimized out>, y=<optimized out>) at drmmode_display.c:918
#12 0x762467e8 in drmmode_set_desired_modes (pScrn=0x67c678, drmmode=<optimized out>, set_hw=1) at drmmode_display.c:3128
#13 0x0047bfa4 in MapWindow (client=0x669ec8, pWin=0x7206c0) at window.c:2722
#14 MapWindow (pWin=0x7206c0, client=0x669ec8) at window.c:2665
#15 0x00449650 in dix_main (argc=3, argv=0x7fa22604, envp=<optimized out>) at main.c:247
#16 0x76ab2198 in __libc_start_main (main=0x42db10 <main>, argc=3, argv=0x7fa22604, init=<optimized out>, fini=0x606434 <__libc_csu_fini>, rtld_fini=0x77229930 <_dl_fini>,
stack_end=0x7fa225e0) at libc-start.c:308
#17 0x0042db80 in __start () at ../sysdeps/mips/start.S:110
Don't call `exaGetPixmapDriverPrivate` if the acceleration (EXA) is not
enabled [yet] to avoid the problem.
Closes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/188
Closes: https://bugzilla.altlinux.org/show_bug.cgi?id=37539
Without the 'extern' this looks like a definition not just a
declaration, in every file that includes the header. gcc 10 is stricter
about this kind of multiple definition.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
FindClientResourcesByType finds pixmaps from all screens, but trying to
process ones from other screens here makes no sense and likely results
in a crash or memory corruption.
Fixes: 06a4654841 ("Make all active CRTCs scan out an all-black
framebuffer in LeaveVT")
Even with SW cursor, page flipping can be used while no X cursor is
visible.
Occurred to me in the context of xorg/xserver#828.
(Ported from amdgpu commit 87f41ace4920fd2069794211683659eb25b025a6)
This can legitimately fail if the pixmap's storage is shared from
another device, e.g. when using PRIME render offloading.
(Ported from amdgpu commit 7d3fef72e0c871e1677e9e544f4cae5e238b5c52)
All callers were passing TRUE.
(Ported from amdgpu commit ea19a5207054bb159fc7fb6d88e0ceb10c3da010)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This way, the MSC will continue ticking at the rate of (the last mode
which was enabled for) that CRTC, instead of the client running
unthrottled.
(Ported from amdgpu commit 3109f088fdbd89c2ee8078625d4f073852492656)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
otherwise client would wait for reply forever and desktop appears hang.
Signed-off-by: Flora Cui <flora.cui@amd.com>
(Ported from amdgpu commit fb06fb814700a47464abd756e1111dcc76d0d776)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Even if glamor_gbm_bo_from_pixmap / glamor_fd_from_pixmap themselves
don't trigger any drawing, there could already be unflushed drawing to
the pixmap whose storage we share with a client.
(Ported from amdgpu commit 4b17533fcb30842caf0035ba593b7d986520cc85)
Acked-by: Alex Deucher <alexander.deucher@amd.com>
If get_fb_ptr returns NULL, try again after pixmap_get_handle, it should
work then.
Fixes spurious Present page flipping failures using "normal" pixmaps
which aren't shared with direct rendering clients, e.g. with a
compositor using the RENDER extension.
Bugzilla: https://bugs.freedesktop.org/110417
(Ported from amdgpu commit bf61e6d7ac1a5754b1026d7f80acf25ef622c491)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This adds tiling support to the driver, it retrieves the tile info from
the kernel and translates it into the server format and exposes the
property.
(Ported from xserver commits 8fb8bbb3062f1a06621ab7030a9e89d5e8367b35
and 6abdb54a11dac4e8854ff94ecdcb90a14321ab31)
(Ported from amdgpu commit 6ee857726166f495abcd68e4ff60e3a09593d079)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 274703087f.
Reports of visual corruption were bisected to this, e.g.
https://bugs.archlinux.org/task/61941 . I can reproduce this with Turks,
but not with Bonaire. I assume it's a Mesa/glamor bug, but let's revert
for now.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
drm_queue_handler just puts the event on the signalled list; without
calling drm_queue_handle_deferred, actual processing of the event may be
delayed indefinitely, e.g. until another event arrives from the kernel.
This could result in DRI2 clients hanging during DPMS off.
Fixes: ba83a866af "Add radeon_drm_handle_event wrapper for
drmHandleEvent"
(Ported from amdgpu commit 09be74a3d1dd9604336d9a27f98d132b262dcbaf)
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
