Re: [BUG] Window resizing broken

2014-04-07 Thread Knut Petersen
On 08.04.2014 02:08, Jasper St. Pierre wrote: Resizing by window borders is a WM operation, is it not? I agree. But the WM relies on services provided by Xorg. What WM are you using, and does it work on other WMs? I'm using KDE, the original openSuSE 13.1 binaries. No other WM tested up to

Re: [PATCH 11/16] glamor: Use glamor_program and GL_LINES for 0-width lines

2014-04-07 Thread Keith Packard
Michel Dänzer writes: > I'm afraid it's not that simple: I was testing with your current > glamor-server branch. Right, I was mistaken about the dependency on the dashing code; the first 0-width line patch does indeed handle all fill styles. I had written the code in a different order, but when

Re: glamor regressions with radeonsi (Re: xserver: Branch 'master' - 15 commits)

2014-04-07 Thread Michel Dänzer
On Mon, 2014-04-07 at 23:39 -0700, Keith Packard wrote: > Michel Dänzer writes: > > > I've come to realize it's coincidence that the text appears at step 2: > > The problem is that a lot of time is spent in glamor_font_get() -> > > glTexSubImage2D(). It would probably be more efficient to pack al

Re: glamor regressions with radeonsi (Re: xserver: Branch 'master' - 15 commits)

2014-04-07 Thread Keith Packard
Michel Dänzer writes: > I've come to realize it's coincidence that the text appears at step 2: > The problem is that a lot of time is spent in glamor_font_get() -> > glTexSubImage2D(). It would probably be more efficient to pack all the > glyphs in malloc()ed memory and pass that to glTexImage2D(

Re: [PATCH 00/20] New glamor core rendering code (v2)

2014-04-07 Thread Keith Packard
Michel Dänzer writes: > The radeon driver doesn't use the glamor_*_nf() entrypoints, it leaves > all the rendering and fallback handling to glamor. Cool. That makes things more similar, unlike uxa which mixes glamor and legacy rendering code in the same driver. > E.g. the GtkComboBox test leave

Re: [PATCH 11/16] glamor: Use glamor_program and GL_LINES for 0-width lines

2014-04-07 Thread Michel Dänzer
On Mon, 2014-04-07 at 23:03 -0700, Keith Packard wrote: > Michel Dänzer writes: > > > On Die, 2014-04-01 at 21:15 -0700, Keith Packard wrote: > >> GL lines are nearly X compliant; you just need to fill in the last > >> pixel when the client hasn't requested CapNotLast. > >> > >> Signed-off-by: K

Re: glamor regressions with radeonsi (Re: xserver: Branch 'master' - 15 commits)

2014-04-07 Thread Michel Dänzer
On Mon, 2014-04-07 at 18:33 +0900, Michel Dänzer wrote: > Test case: > > 1. Start 'naked' Xorg with an xterm: xinit =xterm -- :1 -retro & > 2. Start xfwm4: DISPLAY=:1 xfwm4 & > 3. Maximize and unmaximize xterm window > > > There are at least two regressions introduced by the lates

Re: [PATCH 11/16] glamor: Use glamor_program and GL_LINES for 0-width lines

2014-04-07 Thread Keith Packard
Michel Dänzer writes: > On Die, 2014-04-01 at 21:15 -0700, Keith Packard wrote: >> GL lines are nearly X compliant; you just need to fill in the last >> pixel when the client hasn't requested CapNotLast. >> >> Signed-off-by: Keith Packard > > This doesn't seem to work so well with > http://www.

Re: [PATCH 00/20] New glamor core rendering code (v2)

2014-04-07 Thread Michel Dänzer
On Die, 2014-04-01 at 16:01 -0700, Keith Packard wrote: > Michel Dänzer writes: > > > Sounds great, but... > > > > Patch 11 breaks Xorg for me with radeonsi. It looks like solid fills are > > basically not rendered at all anymore, so e.g. only the text is visible > > in an xterm window. Then late

Re: [PATCH 11/16] glamor: Use glamor_program and GL_LINES for 0-width lines

2014-04-07 Thread Michel Dänzer
On Die, 2014-04-01 at 21:15 -0700, Keith Packard wrote: > GL lines are nearly X compliant; you just need to fill in the last > pixel when the client hasn't requested CapNotLast. > > Signed-off-by: Keith Packard This doesn't seem to work so well with http://www.xfree86.org/~mvojkovi/linetest.c .

Re: [PATCH 3/8] glamor: Stop calling eglMakeCurrent (.., EGL_NO_SURFACE)

2014-04-07 Thread Michel Dänzer
On Mit, 2014-04-02 at 11:46 -0700, Eric Anholt wrote: > Keith Packard writes: > > > This eliminates a huge cost when using EGL. > > > > Signed-off-by: Keith Packard > > It also, as far as I've heard, causes segfaults when you use indirect > GLX. I never quite got my patchset for global GL cont

Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?

2014-04-07 Thread Matt Dew
On 04/04/2014 06:39 AM, Julien Cristau wrote: > On Thu, Apr 3, 2014 at 20:49:53 -0600, Matt Dew wrote: > >> Hey folks, >> Any body have any thing more for xserver stable? Either 1.15.1 or 1.14.6? >> > I requested a cherry-pick in > http://lists.x.org/pipermail/xorg-devel/2014-March/041572.html

Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?

2014-04-07 Thread Rob Clark
Oh, sorry, I was only paying attention to master and not the release branches. I just realized neither 1.14.x or 1.15.x has: 7353ec7cb6f "xfree86: Switch int10 code to stdint types" so you don't actually need these patches. Sorry for the noise. BR, -R On Mon, Apr 7, 2014 at 9:58 PM, Matt De

[PULL] arm build fixes

2014-04-07 Thread Rob Clark
Hi Keith, This pull request doubly fixes build breakage on arm: * my two patches make arm default to stub int10 implementation (and fix stub implementation to actually compile).. this is what 99.9% of folks on ARM want * Thierry's patch actually fixes the real int10 implementation to work for the

Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?

2014-04-07 Thread Matt Dew
Hi Rob, For 1.15.1 or 1.14.6 or both? thanks, Matt On 04/04/2014 06:24 AM, Rob Clark wrote: > Perhaps those two little fixes I sent yesterday to get things building > on ARM again (with default config): > > default to stub int10 implementation on arm > int10: fix build error > > BR, > -

Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?

2014-04-07 Thread Matt Dew
On 04/03/2014 11:30 PM, Eric Anholt wrote: > Matt Dew writes: > >> Hey folks, >> Any body have any thing more for xserver stable? Either 1.15.1 or 1.14.6? >> >> Current plan is one week from today for releases. > > It would be nice to get 96a28e9c914d7ae9b269f73a27b99cbd3c465ac8 picked > bac

[PATCH] multiseat with several videocards

2014-04-07 Thread Floris
This patch is made by Oleg Samarin and was already mailed in September 2013 (http://lists.x.org/archives/xorg-devel/2013-September/037946.html) I hope someone can apply this patch or give me a reason why it isn't. Thanks, jkfloris Added capability of specifying "MatchSeat" option in the ServerL

Re: [PATCH] input: Remove invalid bug checks.

2014-04-07 Thread Peter Hutterer
On Wed, Apr 02, 2014 at 05:14:05PM +0300, Michal Srb wrote: > Commit 2f1aedcaed8fd99b823d451bf1fb02330c078f67 added several bug checks. Some > of them are not correct. > > Checks in Init(Ptr|String|Bell|Led|Integer)FeedbackClassDeviceStruct verify > that no feedback struct was set yet, but that is

Re: glamor regressions with radeonsi (Re: xserver: Branch 'master' - 15 commits)

2014-04-07 Thread Michel Dänzer
On Mon, 2014-04-07 at 11:27 -0700, Keith Packard wrote: > Michel Dänzer writes: > > > Test case: > > > > 1. Start 'naked' Xorg with an xterm: xinit =xterm -- :1 -retro & > > 2. Start xfwm4: DISPLAY=:1 xfwm4 & > > 3. Maximize and unmaximize xterm window > > > > > > There are at leas

Re: [BUG] Window resizing broken

2014-04-07 Thread Jasper St. Pierre
Resizing by window borders is a WM operation, is it not? What WM are you using, and does it work on other WMs? On Mon, Apr 7, 2014 at 2:56 AM, Knut Petersen wrote: > Hi everybody: > > Problem: Resizing of windows is broken as it is impossible to grab a > window border. > > Broken version: > full

Re: [PATCH libXfont] Fix buffer read overrun

2014-04-07 Thread Alan Coopersmith
On 04/ 7/14 01:25 PM, walter harms wrote: Am 07.04.2014 20:29, schrieb Peter Harris: "FreeType" is only eight bytes long. The atom "FreeType\x00\x??" is probably not what the author intended. Signed-off-by: Peter Harris --- src/FreeType/ftfuncs.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH libXfont] Fix buffer read overrun

2014-04-07 Thread walter harms
Am 07.04.2014 20:29, schrieb Peter Harris: > "FreeType" is only eight bytes long. The atom "FreeType\x00\x??" is > probably not what the author intended. > > Signed-off-by: Peter Harris > --- > src/FreeType/ftfuncs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src

Re: [PATCH libXfont] Fix buffer read overrun

2014-04-07 Thread Alan Coopersmith
On 04/ 7/14 11:29 AM, Peter Harris wrote: "FreeType" is only eight bytes long. The atom "FreeType\x00\x??" is probably not what the author intended. Signed-off-by: Peter Harris --- src/FreeType/ftfuncs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/FreeType/ftfuncs

[PATCH libXfont] Fix buffer read overrun

2014-04-07 Thread Peter Harris
"FreeType" is only eight bytes long. The atom "FreeType\x00\x??" is probably not what the author intended. Signed-off-by: Peter Harris --- src/FreeType/ftfuncs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/FreeType/ftfuncs.c b/src/FreeType/ftfuncs.c index 65efefc..a49

Re: glamor regressions with radeonsi (Re: xserver: Branch 'master' - 15 commits)

2014-04-07 Thread Keith Packard
Michel Dänzer writes: > Test case: > > 1. Start 'naked' Xorg with an xterm: xinit =xterm -- :1 -retro & > 2. Start xfwm4: DISPLAY=:1 xfwm4 & > 3. Maximize and unmaximize xterm window > > > There are at least two regressions introduced by the latest glamor > series: Can you try run

[PATCH 2/2] glxproxy: Fix memory leak on error path in CreateGLXPixmap (#50281)

2014-04-07 Thread Adam Jackson
Signed-off-by: Adam Jackson --- hw/dmx/glxProxy/glxcmds.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glxProxy/glxcmds.c index 964db40..f097906 100644 --- a/hw/dmx/glxProxy/glxcmds.c +++ b/hw/dmx/glxProxy/glxcmds.c @@ -2017,6 +2017,7 @@ CreateGLXPixmap(_

[PATCH 1/2] dmx: Fix memory leak in dmxBELoadFont (#50281)

2014-04-07 Thread Adam Jackson
Signed-off-by: Adam Jackson --- hw/dmx/dmxfont.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/dmx/dmxfont.c b/hw/dmx/dmxfont.c index 6b81826..115422d 100644 --- a/hw/dmx/dmxfont.c +++ b/hw/dmx/dmxfont.c @@ -397,12 +397,12 @@ dmxBELoadFont(ScreenPtr pScreen, FontPtr pFont

Re: [PATCH mesa/mesa] Check for dladdr(), rather than assuming we have it if we have RTLD_DEFAULT

2014-04-07 Thread Jon TURNEY
On 07/04/2014 17:07, Eric Anholt wrote: > Jon TURNEY writes: > >> Unfortunately, Cygwin defines RTLD_DEFAULT (for glibc compatibility), but >> can't >> provide dladdr(), so add a check for dladdr() > > This patch is: > > Reviewed-by: Eric Anholt > > I'm confused why you'd be building DRI driv

Re: [PATCH xinit] startx: Pass vtX as long as the user did not specify one

2014-04-07 Thread James Cloos
> "HG" == Hans de Goede writes: HG> This grep is in a #ifdef __linux__ block, so it should be fine. [SIGH] I should have remembered or reconfirmed that. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 ___ xorg-devel@lists.x.org: X.Org devel

Re: [PATCH mesa/mesa] Check for dladdr(), rather than assuming we have it if we have RTLD_DEFAULT

2014-04-07 Thread Eric Anholt
Jon TURNEY writes: > Unfortunately, Cygwin defines RTLD_DEFAULT (for glibc compatibility), but > can't > provide dladdr(), so add a check for dladdr() This patch is: Reviewed-by: Eric Anholt I'm confused why you'd be building DRI driver code on cygwin, but it probably helps DRI driver portab

Re: [PATCH xfs] Fix CFLAGS and LDFLAGS for Cygwin/MinGW

2014-04-07 Thread Gaetan Nadon
On 14-04-06 07:50 PM, Yaakov (Cygwin/X) wrote: > You're referring to using CFLAGS instead of AM_CFLAGS in automake > files. This is appending to (not clobbering) CFLAGS at the configure > level, which still allows the user to override the settings during > make (even though it would be a bad idea

Re: [PATCH xinit] startx: Pass vtX as long as the user did not specify one

2014-04-07 Thread Hans de Goede
Hi, On 04/07/2014 03:05 PM, Gaetan Nadon wrote: > On 14-04-07 07:42 AM, James Cloos wrote: >> But re commit 44915d6953076, >> >> HG> tty_num=$(echo "$tty" | grep -oE '[0-9]+$') >> >> Is grep -o available everwhere startx(1) runs? >> >> The posix page, grep.1p, does not mention -o. >> >>

Re: [PATCH xinit] startx: Pass vtX as long as the user did not specify one

2014-04-07 Thread Gaetan Nadon
On 14-04-07 07:42 AM, James Cloos wrote: > But re commit 44915d6953076, > > HG> tty_num=$(echo "$tty" | grep -oE '[0-9]+$') > > Is grep -o available everwhere startx(1) runs? > > The posix page, grep.1p, does not mention -o. > > It looks like each of the BSDs have adopted it, but only mid

Re: [PATCH] hw/xwin: link dynamically and export symbols

2014-04-07 Thread Jon TURNEY
On 06/04/2014 22:48, Yaakov (Cygwin/X) wrote: > With my patch to fix shared libXfont to work correctly on Cygwin/Win32, > there is no need for -static anymore. But, XWin.exe must export its > symbols in order for them to override libXfont's stubs. Reviewed-by: Jon TURNEY

Re: [PATCH xinit] startx: Pass vtX as long as the user did not specify one

2014-04-07 Thread James Cloos
> "HG" == Hans de Goede writes: HG> Instead always pass the vtX argument, except when the user has specified its HG> own vtX argument. Note that vtX still only gets added for the default server, HG> since for ie Xnest or Xephyr it makes no sense. Reviewed-by: James Cloos But re commit 449

glamor regressions with radeonsi (Re: xserver: Branch 'master' - 15 commits)

2014-04-07 Thread Michel Dänzer
Test case: 1. Start 'naked' Xorg with an xterm: xinit =xterm -- :1 -retro & 2. Start xfwm4: DISPLAY=:1 xfwm4 & 3. Maximize and unmaximize xterm window There are at least two regressions introduced by the latest glamor series: > commit 3c34dd3603989c0365654ca1b6809395c7f3b169 > A

[PATCH xinit] startx: Pass vtX as long as the user did not specify one

2014-04-07 Thread Hans de Goede
Adding vtX to $defaultserverargs means that it will only be added when the user specifies no server arguments. This means that doing ie: "startx -- -depth 16" will cause the server to start on a different vt then just "startx", which does not meat the principle of least surprise. Instead always p

[BUG] Window resizing broken

2014-04-07 Thread Knut Petersen
Hi everybody: Problem: Resizing of windows is broken as it is impossible to grab a window border. Broken version: full xorg git master build, 5. Apr 16:26, xserver git 901fbfbbbd71c0d8208095... Known good version: full xorg git master build, 22. Mar 17:13, xserver git 4fb31e4824d46edc80bb49b