[Bug 94675] issue with mpv using OGL output on latest xf86-video-ati

https://bugs.freedesktop.org/show_bug.cgi?id=94675 Michel Dänzer changed: What|Removed |Added Resolution|--- |FIXED

Re: [PATCH xf86-video-ati] Revert "Use render node for DRI3 if available"

On Thu, Mar 24, 2016 at 10:54 PM, Michel Dänzer wrote: > From: Michel Dänzer > > This reverts commit cd94248ffa7d8fe0b57476f79e7e860dee66d1b0. > > It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU > code doesn't support DRI3 yet.

Re: [PATCH xserver] present: Only requeue for next MSC after flip failure

On 25.03.2016 04:51, Adam Jackson wrote: > On Thu, 2016-03-24 at 07:22 -0600, Keith Packard wrote: >> Michel Dänzer writes: >>> From: Michel Dänzer >>> >>> This code was added to deal with the driver present hook failing, in >>> which case we need to

[PATCH xf86-video-amdgpu] Revert "Use render node for DRI3 if available"

From: Michel Dänzer This reverts commit ea558e645786b08d75307716036045170e97b43e. It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU code doesn't support DRI3 yet. We can consider re-enabling this once there is a Mesa release where the Gallium VDPAU

[PATCH xf86-video-ati] Revert "Use render node for DRI3 if available"

From: Michel Dänzer This reverts commit cd94248ffa7d8fe0b57476f79e7e860dee66d1b0. It broke VDPAU<->GL interop with DRI3 enabled, because the Gallium VDPAU code doesn't support DRI3 yet. We can consider re-enabling this once there is a Mesa release where the Gallium VDPAU

[Bug 94596] xserver-1.18.2 uses one core fully with dri3

https://bugs.freedesktop.org/show_bug.cgi?id=94596 --- Comment #30 from Michel Dänzer --- The fix has landed on the master branch; leaving this report open until it lands on the 1.18 branch. -- You are receiving this mail because: You are the assignee for the

[Bug 94675] issue with mpv using OGL output on latest xf86-video-ati

https://bugs.freedesktop.org/show_bug.cgi?id=94675 --- Comment #2 from John --- That works! Thank you! -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list

Re: [PATCH xserver] present: Only requeue for next MSC after flip failure

On Thu, 2016-03-24 at 07:22 -0600, Keith Packard wrote: > Michel Dänzer writes: > > > > > From: Michel Dänzer > > > > This code was added to deal with the driver present hook failing, in > > which case we need to wait for the next MSC before

Re: Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

I think this should be done at the application level. If an application is running, it has many other ways to fingerprint your computer, including listing the files in your homedir, checking cpuid, MAC address, etc. The issue here is that there is an application platform that runs untrusted user

Re: [PATCH xf86-video-amdgpu 6/6] Require xserver 1.9 or newer

On Thu, Mar 24, 2016 at 6:14 AM, Michel Dänzer wrote: > From: Michel Dänzer > > 1.9.0 was released in August 2010. > > We were already unintentionally relying on things not available in 1.8 > for at least a year, and nobody has complained. > > (Ported

Re: Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

On 2016-03-24 12:45, Pekka Paalanen wrote: Hi, that's interesting. Sounds like you are looking for volunteers to implement what you want, right? Yes please. Unfortunately I don't know C or have the skill to code something like this myself. I skimmed through [3], and I got the impression

Re: [PATCH xserver] present: Only requeue for next MSC after flip failure

Michel Dänzer writes: > From: Michel Dänzer > > This code was added to deal with the driver present hook failing, in > which case we need to wait for the next MSC before executing the > presentation. > > However, it could also take effect in cases

Re: Proposal for Anti-Keystroke Fingerprinting at the Display Server Level

On Wed, 23 Mar 2016 23:49:03 +0100 ban...@openmailbox.org wrote: > == Attack Description == > > Keystroke fingerprinting works by measuring how long keys are pressed > and the time between presses. Its very high accuracy poses a serious > threat to anonymous users.[1] > > This tracking

Flickering single display in multi-head XRandR setup

Hello, I have a new Radeon R9 390 card, driving three monitors, two on DisplayPort and one on DVI, in this order from left to right: DP0 — DVI0 — DP1 Please find my xorg.conf attached, as well as the log file. There is something very weird going on, which you may witness in the video

[Bug 94614] latest xf86-video-ati from git doesn't build

https://bugs.freedesktop.org/show_bug.cgi?id=94614 joro-2013 changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment

[PATCH xf86-video-amdgpu 4/6] DRI3 only works with acceleration

From: Michel Dänzer Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94214 (Ported from radeon commit d21ac4669a8b2cdd4eec5e5a94d1950b7423b8b5) Signed-off-by: Michel Dänzer --- src/amdgpu_kms.c | 15 +-- 1 file changed, 9

[PATCH xf86-video-amdgpu 6/6] Require xserver 1.9 or newer

From: Michel Dänzer 1.9.0 was released in August 2010. We were already unintentionally relying on things not available in 1.8 for at least a year, and nobody has complained. (Ported from radeon commit e592f32f8b5f5873fcc18b10a69dd5e4ccf11073) Signed-off-by: Michel

[PATCH xf86-video-amdgpu 2/6] Don't try DRI2/Present flipping while the HW cursor can't be used

From: Michel Dänzer Flipping doesn't interact correctly with SW cursor: A flip makes the SW cursor disappear. It will only appear again when the cursor is moved, but it will be surrounded by corruption, because the SW cursor code will restore stale screen contents at the

[PATCH xf86-video-amdgpu 1/6] Factor out HW cursor checking code into drmmode_can_use_hw_cursor

From: Michel Dänzer And add a check for RandR 1.4 multihead. (Ported from radeon commit 3de480e83c0a1824838d662d6d67c9fe85277298) Signed-off-by: Michel Dänzer --- src/drmmode_display.c | 39 +-- 1 file

[PATCH xf86-video-amdgpu 3/6] Check for xf86CursorResetCursor

From: Michel Dänzer If it's available, Xorg calls it on each mode configuration change. It does what xf86_reload_cursors does (and more), so we don't need to call the latter anymore. (Ported from radeon commit d670c5c9851b4eff21c845d26c7d7e4eb5ee0fa9) Signed-off-by:

[PATCH xf86-video-amdgpu 5/6] Fix build against older versions of xserver

From: Michel Dänzer Also slightly clean up the error handling in radeon_scanout_do_update. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94614 (Ported from radeon commit bde466e5d44cad64b4e4eceaa5de80fdbf86356e) Signed-off-by: Michel Dänzer

[Bug 94675] issue with mpv using OGL output on latest xf86-video-ati

https://bugs.freedesktop.org/show_bug.cgi?id=94675 --- Comment #1 from Michel Dänzer --- It's cd94248f ("Use render node for DRI3 if available"). The problem is likely related to the Gallium VDPAU code not supporting DRI3 yet. Until that's fixed, you can work around the

Re: [PATCH glx] glx: avoid memory leak when using indirect rendering

I've finally got some time to rewrite this patch and now the solution makes more sense. I'm sending as an attachment. I also have some tests on a github repository to check this bug. I don't know if it is ok to post the link here though. Guilherme On Tue, Dec 8, 2015 at 4:48 PM Guilherme Melo

[PATCH xf86-video-ati] Call RADEONBlockHandler_KMS before setting initial modes

From: Michel Dänzer Doing it the other way around meant that there was still a possibility for the front buffer contents to be uninitialized when they start being scanned out. (Ported from amdgpu commit 4a60b4b1851a3cbc2d8ad9048d68eeb6947cf132) Signed-off-by: Michel

Re: [PATCH xserver] xfree86/modes: Make sure the HW cursor is hidden when it should be

Looks good to me, but I don't feel I'm quite familiar enough with the code to give a full "reviewed-by". Regards, Michael On 24.03.2016 09:34, Michel Dänzer wrote: From: Michel Dänzer When the HW cursor is hidden (e.g. because xf86CursorResetCursor triggers a switch

[Bug 94614] latest xf86-video-ati from git doesn't build

https://bugs.freedesktop.org/show_bug.cgi?id=94614 Michel Dänzer changed: What|Removed |Added Resolution|--- |FIXED

[Bug 94611] Steam client hangs with Radeon DDX + DRI3

https://bugs.freedesktop.org/show_bug.cgi?id=94611 Michel Dänzer changed: What|Removed |Added Resolution|FIXED |DUPLICATE ---

[Bug 94611] Steam client hangs with Radeon DDX + DRI3

https://bugs.freedesktop.org/show_bug.cgi?id=94611 Maxim Sheviakov changed: What|Removed |Added Resolution|--- |FIXED

[Bug 94611] Steam client hangs with Radeon DDX + DRI3

https://bugs.freedesktop.org/show_bug.cgi?id=94611 --- Comment #9 from Maxim Sheviakov --- (In reply to Maxim Sheviakov from comment #8) > (In reply to Maxim Sheviakov from comment #0) > > issue of a recent 1.18.4 X.org update > Sorry, 1.18.2, of course - my bad typo.

[Bug 94596] xserver-1.18.2 uses one core fully with dri3

https://bugs.freedesktop.org/show_bug.cgi?id=94596 --- Comment #27 from Maxim Sheviakov --- (In reply to Michel Dänzer from comment #23) > Created attachment 122489 [details] [review] > Only requeue for the next MSC > > While it's looking from bug 94515 like this is

[Bug 94611] Steam client hangs with Radeon DDX + DRI3

https://bugs.freedesktop.org/show_bug.cgi?id=94611 --- Comment #8 from Maxim Sheviakov --- (In reply to Maxim Sheviakov from comment #0) > issue of a recent 1.18.4 X.org update Sorry, 1.18.2, of course - my bad typo. Anyway, I'll be doing some testing with the workaround

[PATCH xserver] present: Only requeue for next MSC after flip failure

From: Michel Dänzer This code was added to deal with the driver present hook failing, in which case we need to wait for the next MSC before executing the presentation. However, it could also take effect in cases where the driver incorrectly thinks the current MSC matches

[PATCH xserver] xfree86/modes: Make sure the HW cursor is hidden when it should be

From: Michel Dänzer When the HW cursor is hidden (e.g. because xf86CursorResetCursor triggers a switch from HW cursor to SW cursor), the driver isn't notified of this for disabled CRTCs. If the HW cursor was shown when the CRTC was disabled, it may still be displayed when