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

Michel Dänzer writes: > Current xserver master takes on the order of ten seconds to start up > xterm on my Kaveri box. I'm sure you agree that's not acceptable. :) That's gotta be a performance problem in the GL driver then; we're uploading on the order of 200 teeny little textures. Perhaps you

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

On Die, 2014-04-08 at 00:00 -0700, Keith Packard wrote: > Michel Dänzer writes: > > > Current xserver master takes on the order of ten seconds to start up > > xterm on my Kaveri box. I'm sure you agree that's not acceptable. :) > > That's gotta be a performance problem in the GL driver then; we'

Re: [BUG] Window resizing broken

On 2014-04-08 08:57 (GMT+0200) Knut Petersen composed: 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

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

On Mon, 2014-04-07 at 23:53 -0700, Keith Packard wrote: > 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 a

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

On Mon, 2014-04-07 at 23:36 -0700, Keith Packard wrote: > Michel Dänzer writes: > > > E.g. the GtkComboBox test leaves artifacts outside of the gtkperf > > window, or also just scrolling the gtkperf widget containing the test > > results. > > > > I think at least part of the problem is using glCo

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

Michel Dänzer writes: > Yes, that works fine now in Xephyr. The only remaining obvious problem > there is the xfwm4 window decoration corruption regression from the > master branch. Ok, looks like that's caused by glamor re-using FBOs that were too large for tile pixmaps. Oddly, the texture fetc

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

Michel Dänzer writes: > I think the glamor code is doing conceptually the wrong thing anyway: > glTexSubImage is intended for changing parts of an existing texture. I'd hate to try and understand the 'intent' of any standard as complex as this, but glTexSubImage seemed to me the 'obvious' way to

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

Michel Dänzer writes: > It's working for me as well now with the current glamor-server branch. > Not sure what the problem was with the previous snapshot. That's good to hear. Perhaps my random force-updates to this branch caused you to run some intermediate version that was actually broken. --

Re: [PATCH] multiseat with several videocards

Hi! An updated version of this patch was submitted last week. Please consider it instead. http://lists.x.org/archives/xorg-devel/2014-April/041690.html CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio 2014-04-07 10:09 GMT-03:00 Floris : > This patch is made by Oleg Samarin and was

[PATCH] busfault: Quash a valgrind complaint

Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s) at 0x388520F85A: __libc_sigaction (sigaction.c:64) by 0x468161: busfault_init (busfault.c:145) by 0x46E09A: OsInit (osinit.c:191) by 0x43A3EA: dix_main (main.c:163) by 0x3884A21D64: (below main) (lib

Re: [PATCH] busfault: Quash a valgrind complaint

On 8 April 2014 15:05, Adam Jackson wrote: > Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s) > at 0x388520F85A: __libc_sigaction (sigaction.c:64) > by 0x468161: busfault_init (busfault.c:145) > by 0x46E09A: OsInit (osinit.c:191) > by 0x43A3EA: dix_mai

Re: [PATCH] busfault: Quash a valgrind complaint

On Tue, 2014-04-08 at 15:30 +0200, Daniel Martin wrote: > Eric sent a patch for this earlier: > http://lists.x.org/archives/xorg-devel/2014-April/041714.html Hah, indeed he did. Withdrawn, and for Eric's: Reviewed-by: Adam Jackson - ajax ___ xo

[PATCH 3/3] configure.ac: Remove check for WAYLAND_SCANNER_RULES

This makes configure fail if the wayland autoconf macros aren't found. We don't need the scanner for shm-only xwayland so just drop this line for now. Signed-off-by: Kristian Høgsberg --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index 70eceab..c

[PATCH 1/3] xwayland: Build without GLX extension

Signed-off-by: Kristian Høgsberg --- hw/xwayland/xwayland.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c index c2c6481..5cecefd 100644 --- a/hw/xwayland/xwayland.c +++ b/hw/xwayland/xwayland.c @@ -616,8 +616,10 @@ xwl_l

[PATCH 2/3] xwayland: Build without xshmfence

Signed-off-by: Kristian Høgsberg --- hw/xwayland/xwayland.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c index 5cecefd..844745a 100644 --- a/hw/xwayland/xwayland.c +++ b/hw/xwayland/xwayland.c @@ -573,8 +573,10 @@ xwl_screen_init(ScreenPtr

Re: Xwayland DDX: build breaks in configuration

On Sun, Apr 6, 2014 at 8:05 AM, Gaetan Nadon wrote: > On 14-04-06 06:02 AM, Yaakov (Cygwin/X) wrote: > > Any idea how to fix this? I would prefer that the RC I'm still trying to > construct will build for most people... > > > Adding a copy of wayland-scanner.m4 to m4/ should work. > > This would w

Re: [PATCH 2/3] xwayland: Build without xshmfence

Hi, On 8 April 2014 17:24, Kristian Høgsberg wrote: > diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c > index 5cecefd..844745a 100644 > --- a/hw/xwayland/xwayland.c > +++ b/hw/xwayland/xwayland.c > @@ -573,8 +573,10 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char > **argv) > >

Re: [PATCH 2/3] xwayland: Build without xshmfence

On Tue, Apr 8, 2014 at 10:13 AM, Daniel Stone wrote: > Hi, > > On 8 April 2014 17:24, Kristian Høgsberg wrote: >> >> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c >> index 5cecefd..844745a 100644 >> --- a/hw/xwayland/xwayland.c >> +++ b/hw/xwayland/xwayland.c >> @@ -573,8 +573,10 @

Re: [PATCH 2/3] xwayland: Build without xshmfence

Hi, On 8 April 2014 18:21, Kristian Høgsberg wrote: > On Tue, Apr 8, 2014 at 10:13 AM, Daniel Stone > wrote: > > Doesn't this also need the syncshm.h include guarded? > > No, the header is just the protoype for miSyncShmScreenInit(). > Oh sure, was just that the last time I reviewed xwayland p

[PATCH] hw/xfree86: Fix block handler wrapping in xf86Rotate

There are a few modules in the X server which dynamically add and remove themselves from the screen block handler chain: * xf86Rotate * miSprite * composite * render (for animated cursors) Correctly manipulating this chain is complicated by the fact that the chain is constructed through a seq

[PATCH] dri3: Fix dri3_open API change by adding new dri3_open_client

Xwayland will eventually need the current client in dri3_open. Simply changing that API is not an option though as other drivers that implement DRI3 will not have a matching function signature and will crash when called. Add a new dri3_open_client function pointer and bump DRI3_SCREEN_INFO_VERSION

Re: [PATCH 3/3] configure.ac: Remove check for WAYLAND_SCANNER_RULES

On 14-04-08 12:24 PM, Kristian Høgsberg wrote: > This makes configure fail if the wayland autoconf macros aren't found. > We don't need the scanner for shm-only xwayland so just drop this line for > now. > > Signed-off-by: Kristian Høgsberg > --- > configure.ac | 1 - > 1 file changed, 1 deletion

Re: Xwayland DDX: build breaks in configuration

On 14-04-08 12:35 PM, Kristian Høgsberg wrote: > %-protocol.c : %.xml > $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@ > > %-client-protocol.h : %.xml > $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@ > > Anyway, patch is on the list to remove the configure.ac macro along > with

Re: [PATCH] dri3: Fix dri3_open API change by adding new dri3_open_client

Keith Packard writes: > Xwayland will eventually need the current client in dri3_open. Simply > changing that API is not an option though as other drivers that > implement DRI3 will not have a matching function signature and will > crash when called. > > Add a new dri3_open_client function pointe

Re: [PATCH v2 RESEND 0/5] Support autoloading of non-PCI drivers

Keith, any news on this? Did this miss 1.16? On 03/28/2014 12:43 PM, David Herrmann wrote: Any comments on that? Anything we can do to get that merged? Thanks David On Fri, Mar 14, 2014 at 4:54 PM, Aaron Plattner wrote: Keith asked me to resend these. I rebased this on top of the systemd-l

[PATCH synaptics 6/6] conf: expand DMI strings to more precise matches

Signed-off-by: Peter Hutterer --- conf/11-x11-synaptics.fdi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/11-x11-synaptics.fdi b/conf/11-x11-synaptics.fdi index 72c3888..eed2694 100644 --- a/conf/11-x11-synaptics.fdi +++ b/conf/11-x11-synaptics.fdi @@ -38,7 +38,7 @@

[PATCH synaptics 5/6] conf: add the L440, X1C to the pnpids

Signed-off-by: Peter Hutterer --- conf/11-x11-synaptics.fdi | 3 ++- conf/50-synaptics.conf| 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/conf/11-x11-synaptics.fdi b/conf/11-x11-synaptics.fdi index a898875..72c3888 100644 --- a/conf/11-x11-synaptics.fdi +++ b/conf/1

[PATCH synaptics 4/6] Comment the touch states

Everytime I look at this I get confused about OPEN_EMPTY vs EMPTY. Let's fix that. Signed-off-by: Peter Hutterer --- src/synproto.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/synproto.h b/src/synproto.h index d81ee42..c52838c 100644 --- a/src/synproto.h ++

[PATCH synaptics 1/6] eventcomm: drop superflous helper function

last_mt_vals_slot is only used in one location and there we can just use cur_slot Signed-off-by: Peter Hutterer --- src/eventcomm.c | 12 +--- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/eventcomm.c b/src/eventcomm.c index 858efeb..5030150 100644 --- a/src/eventcomm

[PATCH synaptics 2/6] eventcomm: read one more event after finishing a sync

Once the sync finishes, we get -EAGAIN. This only indicates the sync is done, but some events may still be waiting in the pipe for us to read. We must read those now, otherwise select may not trigger on further data. Signed-off-by: Peter Hutterer --- src/eventcomm.c | 4 +++- 1 file changed, 3 i

[PATCH synaptics 3/6] eventcomm: Hook up the libevdev log handler

This is a bit problematic: libevdev only has one global log handler. So if we have another driver use libevdev, we'll either overwrite that handler or get overwritten, whichever comes first. So we need to re-set the handler every time we get an event to make sure we log through our handler. Likewis

Re: [BUG] Window resizing broken

On 08.04.2014 09:15, Felix Miata wrote: Works in KDE in 13.1 and 13.2 just fine here. Last booted a few hours ago, 13.1: http://fm.no-ip.com/SS/Xorg/Pass/panning1920x1200on1440x0900server11599901073045-rv370atiVGA-os131kde4115.png and 13.2 before http://fm.no-ip.com/SS/Xorg/Pass/panning2560x16