[Bug 110138] Adaptive Sync, VRR, FreeSync out of range

2019-03-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110138

--- Comment #1 from gr...@sub.red ---
Created attachment 143689
  --> https://bugs.freedesktop.org/attachment.cgi?id=143689=edit
parsed edid

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

[Bug 110138] New: Adaptive Sync, VRR, FreeSync out of range

2019-03-15 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=110138

Bug ID: 110138
   Summary: Adaptive Sync, VRR, FreeSync out of range
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/AMDgpu
  Assignee: xorg-driver-ati@lists.x.org
  Reporter: gr...@sub.red
QA Contact: xorg-t...@lists.x.org

Created attachment 143688
  --> https://bugs.freedesktop.org/attachment.cgi?id=143688=edit
raw edid

Hi,

my monitor has a FreeSync range from 35 to 90 Hz. The maximum supported refresh
rate is 144, which I use by default.

When switching mode to a refresh rate >90 (120 or 144), the monitor's HUD says
that FreeSync is now disabled. On Windows, this is the case.

However, VRR is still being enabled with 144 Hz on Linux 5.0, mesa 19 and
xf86-video-amdgpu 19. It results in heavy artifacts, the timing is broken so
that even the monitor HUD is broken.

I've attached the monitor's EDID.

Regards

-- 
You are receiving this mail because:
You are the assignee for the bug.___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Bug#924540: [PATCH xf86-video-ati] Use radeon_finish in drmmode_crtc_scanout_update

2019-03-15 Thread Alex Deucher
On Fri, Mar 15, 2019 at 4:25 AM Michel Dänzer  wrote:
>
> From: Michel Dänzer 
>
> radeon_glamor_finish only works if we're using glamor, otherwise it'll
> crash.
>
> Fixes: ce7db51020d3 "Cancel pending scanout update in 
> drmmode_crtc_scanout_update"
> Bug: https://bugs.debian.org/924540
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  src/drmmode_display.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/drmmode_display.c b/src/drmmode_display.c
> index c5fccd2aa..002513f1a 100644
> --- a/src/drmmode_display.c
> +++ b/src/drmmode_display.c
> @@ -785,7 +785,7 @@ drmmode_crtc_scanout_update(xf86CrtcPtr crtc, 
> DisplayModePtr mode,
>  
> screen->GetWindowPixmap(screen->root),
>  extents)) {
> 
> RegionEmpty(DamageRegion(drmmode_crtc->scanout_damage));
> -   radeon_glamor_finish(scrn);
> +   radeon_finish(scrn, 
> drmmode_crtc->scanout[scanout_id].bo);
>
> if (!drmmode_crtc->flip_pending) {
> radeon_drm_abort_entry(drmmode_crtc->
> --
> 2.20.1
>
> ___
> xorg-driver-ati mailing list
> xorg-driver-ati@lists.x.org
> https://lists.x.org/mailman/listinfo/xorg-driver-ati

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Bug#924540: xserver-xorg-video-radeon: undefined symbol: glamor_finish when AccelMethod is EXA and TearFree is on

2019-03-15 Thread Michel Dänzer
On 2019-03-13 11:28 p.m., Antonio Ospite wrote:
> Package: xserver-xorg-video-radeon
> Version: 1:19.0.0-1
> Severity: minor
> 
> Dear Maintainer,
> 
> when upgrading from 18.1.0-1 to 18.1.99+git20190207-1 (or 19.0.0-1) Xorg
> failed to start on my system with the following error in the logs:
> 
> mar 13 23:06:44 jcn /usr/lib/gdm3/gdm-x-session[12568]: /usr/lib/xorg/Xorg: 
> symbol lookup error: /usr/lib/xorg/modules/drivers/radeon_drv.so: undefined 
> symbol: glamor_finish
> 
> at first I worked around the problem by downgrading the package.
> 
> However upon further investigation it turned out I had some old custom
> config in /usr/share/X11/xorg.conf.d/ which breaks new versions of the
> driver.
> 
> In particular, having both the settngs below in
> /usr/share/X11/xorg.conf.d/10-radeon.conf makes Xorg fail to start when
> using the xserver-xorg-video-radeon driver:
> 
>   Option "AccelMethod" "EXA"
>   Option "TearFree" "on"
> 
> Anyway, removing these options fixes the issue for me.
> 
> Not sure if this is a regression [...]

It is, thanks for the report. Fixed by
https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/commit/79bc0e054f37026377d54cac6cd8127d4aa9baca
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati

Bug#924540: [PATCH xf86-video-ati] Use radeon_finish in drmmode_crtc_scanout_update

2019-03-15 Thread Michel Dänzer
From: Michel Dänzer 

radeon_glamor_finish only works if we're using glamor, otherwise it'll
crash.

Fixes: ce7db51020d3 "Cancel pending scanout update in 
drmmode_crtc_scanout_update"
Bug: https://bugs.debian.org/924540
Signed-off-by: Michel Dänzer 
---
 src/drmmode_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c5fccd2aa..002513f1a 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -785,7 +785,7 @@ drmmode_crtc_scanout_update(xf86CrtcPtr crtc, 
DisplayModePtr mode,
 
screen->GetWindowPixmap(screen->root),
 extents)) {
RegionEmpty(DamageRegion(drmmode_crtc->scanout_damage));
-   radeon_glamor_finish(scrn);
+   radeon_finish(scrn, 
drmmode_crtc->scanout[scanout_id].bo);
 
if (!drmmode_crtc->flip_pending) {
radeon_drm_abort_entry(drmmode_crtc->
-- 
2.20.1

___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati