[PATCH xf86-video-dummy 3/4] Remove DGA support

DGA was so 2004. Signed-off-by: Bob Terek --- configure.ac | 8 --- src/Makefile.am| 5 -- src/dummy.h| 7 --- src/dummy_dga.c| 175 - src/dummy_driver.c | 8 --- 5 files changed, 203

[PATCH xf86-video-dummy 4/4] Get rid of dPtr->FBBase

The pointer to the screen's pixels is stored in the screen pixmap's devPrivate.ptr field. Just use that instead of storing it redundantly. In addition, don't leak the screen if the server was VT switched. Signed-off-by: Bob Terek --- src/dummy.h| 1 -

[PATCH xf86-video-dummy 2/4] Delete dPtr->screenSaver

This is assigned, but never used. Signed-off-by: Bob Terek --- src/dummy.h| 1 - src/dummy_driver.c | 9 - 2 files changed, 10 deletions(-) diff --git a/src/dummy.h b/src/dummy.h index c231be4..705b9e5 100644 --- a/src/dummy.h +++ b/src/dummy.h @@ -56,7 +56,6

[PATCH xf86-video-dummy 0/4] Cleanups Redux

Resubmitting some of Aaron Plattner's cleanup patches to xf86-video-dummy: https://lists.x.org/archives/xorg-devel/2015-January/045395.html This series contains Aaron's patches numbered 2 - 5, as patch 1 has already been applied, and patch 6 introduced new functionality. Bob Terek (4):

[PATCH xf86-video-dummy 1/4] Delete XV stuff

As far as anyone can tell, this was never implemented or used. Signed-off-by: Bob Terek --- configure.ac | 1 - src/dummy.h| 11 --- src/dummy_driver.c | 7 --- 3 files changed, 19 deletions(-) diff --git a/configure.ac b/configure.ac index

Re: [PATCH xserver] composite: Fix repaint of borders (v2)

Adam Jackson writes: > When going from border width zero to a non-zero border width, the > Composite extension is informed via the ConfigNotify callback. The > call-chain looks like this: compConfigNotify -> compReallocPixmap -> > compSetPixmap -> TraverseTree ->

Re: [PATCH libXpm] Gracefully handle EOF while parsing files.

On Tue, Dec 06, 2016 at 10:34:33PM +0100, Matthieu Herrb wrote: This is from https://bugs.freedesktop.org/show_bug.cgi?id=98878 > From: Tobias Stoeckmann > > libXpm does not properly handle EOF conditions when xpmGetC is called > multiple times in a row to construct a

Re: [PATCH libXpm] Fix out out boundary read on unknown colors

On Tue, Dec 06, 2016 at 10:31:53PM +0100, Matthieu Herrb wrote: This is from https://bugs.freedesktop.org/show_bug.cgi?id=98877 > From: Tobias Stoeckmann > > libXpm is vulnerable to an out of boundary read if an XPM file contains > a color with a symbolic name but

Re: [patch libICE] Fix use after free on subsequent calls

On Tue, Dec 06, 2016 at 10:26:59PM +0100, Matthieu Herrb wrote: This is from https://bugs.freedesktop.org/show_bug.cgi?id=98822 > From: Tobias Stoeckmann > > The function IceAuthFileName is vulnerable to a use after free. The > flaw can be triggered by calling the

[PATCH libXpm] Gracefully handle EOF while parsing files.

From: Tobias Stoeckmann libXpm does not properly handle EOF conditions when xpmGetC is called multiple times in a row to construct a string. Instead of checking its return value for EOF, the result is automatically casted into a char and attached to a string. By carefully

[patch libICE] Fix use after free on subsequent calls

From: Tobias Stoeckmann The function IceAuthFileName is vulnerable to a use after free. The flaw can be triggered by calling the function three times: - First call succeeds and stores the path in buf, a dynamically allocated buffer with size bsize. - Second call fails

[PATCH libXpm] Fix out out boundary read on unknown colors

From: Tobias Stoeckmann libXpm is vulnerable to an out of boundary read if an XPM file contains a color with a symbolic name but without any default color value. A caller must set XpmColorSymbols and a color with a NULL name in the supplied XpmAttributes to

[PATCH xserver] composite: Fix repaint of borders (v2)

When going from border width zero to a non-zero border width, the Composite extension is informed via the ConfigNotify callback. The call-chain looks like this: compConfigNotify -> compReallocPixmap -> compSetPixmap -> TraverseTree -> compSetPixmapVisitWindow. However, at this time,

Re: [RFC] Why Xorg waits for long time(200ms+) to invoke VT_RELDISP?

On Thu, 2016-11-17 at 14:18 +0800, Yu Chen wrote: > May I know why Xorg takes 200ms+ before acking with VT_RELDISP? Because it's been asked to set the hardware back to text mode, which requires reprogramming the GPU, which takes time. 200ms is more time than it probably _should_ take, but you

Re: [xserver PULL master] randr fixes + primary GPU fallback

On Tue, 2016-12-06 at 15:22 +0100, Hans de Goede wrote: > Hi, > > On Mon Dec 5 16:54:51 UTC 2016, Adam Jackson wrote: >  > Not a fan of the autobind patch in terms of upstreaming, I feel like we >  > really should be able to do better. > > We've had years to do better And? This is seat

[PATCH xserver v3] autobind GPUs to the screen

From: Dave Airlie This is a modified version of a patch we've been carry-ing in Fedora and RHEL for years now. This patch automatically adds secondary GPUs to the master as output sink / offload source making e.g. the use of slave-outputs just work, with requiring the user to

Re: [xserver PULL master] randr fixes + primary GPU fallback

Hi, On Mon Dec 5 16:54:51 UTC 2016, Adam Jackson wrote: > Not a fan of the autobind patch in terms of upstreaming, I feel like we > really should be able to do better. We've had years to do better and carried this patch in both Fedora and RHEL for years and nothing better materialized, I think