Re: [PATCH 1/2] glamor: Add GLAMOR_ACCESS_WO

2016-08-23 Thread Michel Dänzer 

Adding Marek and Nicolai, maybe they have some feedback from a GL
(driver) perspective.


On 23/08/16 10:41 AM, Dave Airlie wrote:
> From: Michel Dänzer 
> 
> [airlied: rebased onto master -
> I left WO alone as it's more like the GL interface
> review suggested changing it to bits.]

After realizing that patch 2 can only affect the !ZPixmap case, I tested
this series with

 x11perf -putimagexy{10,100,500} -shmputxy{10,100,500}

and to my surprise, all of the numbers went down by around an order of
magnitude (using radeonsi on Kaveri). I investigated a little bit what's
going on:


> @@ -86,7 +86,10 @@ glamor_prep_pixmap_box(PixmapPtr pixmap, glamor_access_t 
> access, BoxPtr box)
>  if (priv->pbo == 0)
>  glGenBuffers(1, >pbo);
>  
> -gl_usage = GL_STREAM_READ;
> +if (access == GLAMOR_ACCESS_WO)
> +gl_usage = GL_STREAM_DRAW;
> +else
> +gl_usage = GL_STREAM_READ;
>  
>  glBindBuffer(GL_PIXEL_PACK_BUFFER, priv->pbo);
>  glBufferData(GL_PIXEL_PACK_BUFFER,

This change results in write-combining for the PBO CPU mapping.
Apparently, fbPutXYImage ends up either reading from the PBO, or at
least writing to it in a WC-unfriendly manner, causing a big slowdown.

Reverting this hunk makes performance match or exceed the level before
this series, except for -putimagexy10 remaining at ~50%. Another issue
there is the PBO allocation overhead[0]. Changing glamor_prep_pixmap_box
to use the non-PBO path for GLAMOR_ACCESS_WO[1] makes all numbers match
or exceed (by several times for the 10x10 tests) those before this series.

[0] The PBO must be large enough to hold the destination pixmap, which
is the screen pixmap in the non-composited case, so it's several MBs.
This probably blows up the userspace BO cache, and TTM clears all pages
of the BOs allocated from the kernel, even though most of them end up
completely unused.

[1] A better heuristic for not using a PBO might be based on the
relative size (and maybe also the absolute sizes) of the box and the pixmap.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: display/GFX issue with Ubuntu 16.04 not seen in 14.04

2016-08-23 Thread Felix Miata 

Thomas Lübking composed on 2016-08-23 16:49 (UTC+0200):


On Tue, Aug 23, 2016 at 06:53:13AM -0400, Jim Abernathy wrote:

...

I've tried this on different computers all with Intel GFX. same results.

...

Though this is very most likely a bug in the kernel and not in X11,
check whether you're using the intel (likely) or the modesetting driver,
then use the other one (uninstalling xf86-video-intel could be
sufficient for this, but I never used ubuntu. Ask them.)


http://www.phoronix.com/scan.php?page=news_item=Ubuntu-Debian-Abandon-Intel-DDX 
seems a decent summary of the Intel vs. Modesetting driver situation. The 
Modesetting driver was moved from a standalone package into the server in 
1.17.0, long before 16.04 with server 1.18.3 was released. So far, all my 
Intel gfx installations that work at all with the Modesetting driver work at 
least as well as they ever did with the Intel driver.



Since it's also likely a bug in the kernel, check "dmesg | grep intel"
before doing so. You might face the same issue as this guy:
https://bbs.archlinux.org/viewtopic.php?id=216088

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: display/GFX issue with Ubuntu 16.04 not seen in 14.04

2016-08-23 Thread Thomas Lübking 

On Tue, Aug 23, 2016 at 06:53:13AM -0400, Jim Abernathy wrote:



On 08/19/2016 10:17 AM, Jim Abernathy wrote:
Not having much luck with the Distro forums on this issue so I 
thought I'd ask for advice here.


I've been running Ubuntu 14.04.5 for some time on Intel Core i5 GFX 
without any issues.  My display is HDMI from the PC to an Onkyo A/V 
receiver then to a Sony KDL-XBR6.


When I try a fresh install of 16.04.1, I get a display that blanks 
out for 3-5 seconds at random times depending on what is being 
displayed at the time.  I also have small abouts of video noise that 
is random horizontal lines about 1 pixel tall scattered through the 
page.


I noticed that 14.04.05 uses X server 1.17.2 and 16.04.1 uses 1.18.3.

When I do the command xrandr --verbose I see some small differences 
between 14.04 and 16.04, but it's things like 2 digits displayed 
instead of 1.  i.e. 60.0 vs. 60.00. I'm only concerned with 1080P 
HD.


I've tried this on different computers all with Intel GFX. same results.

This does not occur on other monitors or TVs.

I'd blame it on Sony and Onkyo if they didn't work so well with 
Windows, all versions, and ubuntu all versions except 16.04.


It's almost like the auto detection software in the newest version 
of X is off just enough to make my display flaky.  Kind of like the 
old analog CRT TVs that were sensitive to small tweaks to the 
horizontal and vertical adjustments.


Any help would be appreciated.

Jim A



Can someone let me know where I can ask questions regarding problems 
with X??  I thought this forum would be the place?


Though this is very most likely a bug in the kernel and not in X11,
check whether you're using the intel (likely) or the modesetting driver,
then use the other one (uninstalling xf86-video-intel could be
sufficient for this, but I never used ubuntu. Ask them.)

Since it's also likely a bug in the kernel, check "dmesg | grep intel"
before doing so. You might face the same issue as this guy:
https://bbs.archlinux.org/viewtopic.php?id=216088

Cheers,
Thomas
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH xserver] xi2: fix FocusIn grabs

2016-08-23 Thread Peter Hutterer 
From: Michael Thayer 

Fix a couple of copy-and-paste errors preventing FocusIn grabs from working.
Perhaps the extension version should be bumped though to distinguish between
working and non-working extension versions.

Signed-off-by: Michael Thayer 
Reviewed-by: Peter Hutterer 
---
Michael, sorry about the delay.

 dix/events.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/dix/events.c b/dix/events.c
index 8efdf18..6610b91 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -2892,7 +2892,7 @@ ActivateFocusInGrab(DeviceIntPtr dev, WindowPtr old, 
WindowPtr win)
 
 if (dev->deviceGrab.grab) {
 if (!dev->deviceGrab.fromPassiveGrab ||
-dev->deviceGrab.grab->type != XI_Enter ||
+dev->deviceGrab.grab->type != XI_FocusIn ||
 dev->deviceGrab.grab->window == win ||
 IsParent(dev->deviceGrab.grab->window, win))
 return FALSE;
@@ -2915,7 +2915,7 @@ ActivateFocusInGrab(DeviceIntPtr dev, WindowPtr old, 
WindowPtr win)
 rc = (CheckPassiveGrabsOnWindow(win, dev, (InternalEvent *) , FALSE,
 TRUE) != NULL);
 if (rc)
-DoEnterLeaveEvents(dev, dev->id, old, win, XINotifyPassiveUngrab);
+DoEnterLeaveEvents(dev, dev->id, old, win, XINotifyPassiveGrab);
 return rc;
 }
 
-- 
2.7.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xfree86: print the module name together with the load failure message

2016-08-23 Thread Peter Hutterer 
On Tue, Aug 23, 2016 at 10:29:37AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 23-08-16 06:47, Peter Hutterer wrote:
> > We're happily printing the error to the log but not which module caused 
> > it...
> > That's in the Xorg.log but that's at least one click away.
> > 
> > Signed-off-by: Peter Hutterer 
> 
> LGTM:
> 
> Reviewed-by: Hans de Goede 

thanks. fwiw, I swapped "to the log" to "to stdout" in the commit message
before pushing, it's too confusing otherwise.

   be334f4..25e4f9e  master -> master

Cheers,
   Peter

> 
> > ---
> >  hw/xfree86/loader/loadmod.c | 35 +++
> >  1 file changed, 19 insertions(+), 16 deletions(-)
> > 
> > diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
> > index 702d4e7..8bf6836 100644
> > --- a/hw/xfree86/loader/loadmod.c
> > +++ b/hw/xfree86/loader/loadmod.c
> > @@ -626,9 +626,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo 
> > * data,
> >  else
> >  errtype = X_ERROR;
> >  xf86MsgVerb(errtype, 0,
> > -"module ABI major version (%d) doesn't"
> > +"%s: module ABI major version (%d) doesn't"
> >  " match the server's version (%d)\n",
> > -abimaj, vermaj);
> > +module, abimaj, vermaj);
> >  if (!(LoaderOptions & LDR_OPT_ABI_MISMATCH_NONFATAL))
> >  return FALSE;
> >  }
> > @@ -638,9 +638,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo 
> > * data,
> >  else
> >  errtype = X_ERROR;
> >  xf86MsgVerb(errtype, 0,
> > -"module ABI minor version (%d) is "
> > +"%s: module ABI minor version (%d) is "
> >  "newer than the server's version "
> > -"(%d)\n", abimin, vermin);
> > +"(%d)\n", module, abimin, vermin);
> >  if (!(LoaderOptions & LDR_OPT_ABI_MISMATCH_NONFATAL))
> >  return FALSE;
> >  }
> > @@ -651,24 +651,24 @@ CheckVersion(const char *module, 
> > XF86ModuleVersionInfo * data,
> >  if (req) {
> >  if (req->majorversion != MAJOR_UNSPEC) {
> >  if (data->majorversion != req->majorversion) {
> > -xf86MsgVerb(X_WARNING, 2, "module major version (%d) "
> > +xf86MsgVerb(X_WARNING, 2, "%s: module major version (%d) "
> >  "doesn't match required major version (%d)\n",
> > -data->majorversion, req->majorversion);
> > +module, data->majorversion, req->majorversion);
> >  return FALSE;
> >  }
> >  else if (req->minorversion != MINOR_UNSPEC) {
> >  if (data->minorversion < req->minorversion) {
> > -xf86MsgVerb(X_WARNING, 2, "module minor version (%d) "
> > +xf86MsgVerb(X_WARNING, 2, "%s: module minor version 
> > (%d) "
> >  "is less than the required minor version 
> > (%d)\n",
> > -data->minorversion, req->minorversion);
> > +module, data->minorversion, 
> > req->minorversion);
> >  return FALSE;
> >  }
> >  else if (data->minorversion == req->minorversion &&
> >   req->patchlevel != PATCH_UNSPEC) {
> >  if (data->patchlevel < req->patchlevel) {
> > -xf86MsgVerb(X_WARNING, 2, "module patch level (%d) 
> > "
> > +xf86MsgVerb(X_WARNING, 2, "%s: module patch level 
> > (%d) "
> >  "is less than the required patch level 
> > (%d)\n",
> > -data->patchlevel, req->patchlevel);
> > +module, data->patchlevel, 
> > req->patchlevel);
> >  return FALSE;
> >  }
> >  }
> > @@ -677,8 +677,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo 
> > * data,
> >  if (req->moduleclass) {
> >  if (!data->moduleclass ||
> >  strcmp(req->moduleclass, data->moduleclass)) {
> > -xf86MsgVerb(X_WARNING, 2, "Module class (%s) doesn't match 
> > "
> > +xf86MsgVerb(X_WARNING, 2, "%s: Module class (%s) doesn't 
> > match "
> >  "the required class (%s)\n",
> > +module,
> >  data->moduleclass ? data->moduleclass : 
> > "",
> >  req->moduleclass);
> >  return FALSE;
> > @@ -686,8 +687,9 @@

[Bug 97119] screen distortion under KDE when running without compositor

2016-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97119

--- Comment #4 from Johannes Hirte  ---
I've noticed now, that with modesetting the flickering happens too. Again it's
happening when putting a video into fullscreen and switching to another virtual
desktop of KDE. It's not as heavy as with amdgpu, so I didn't noticed this
before.

-- 
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 97228] Video acceleration *regression* for Radeon Xpress 200M (r300) in xorg-lts-xenial & xorg-lts-wily

2016-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97228

--- Comment #5 from Dennis Mayr  ---
Comment on attachment 125577
  --> https://bugs.freedesktop.org/attachment.cgi?id=125577
Xorg.0.log XENIAL - regression

Xorg version is 7.7

-- 
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 97228] Video acceleration *regression* for Radeon Xpress 200M (r300) in xorg-lts-xenial & xorg-lts-wily

2016-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97228

--- Comment #4 from Dennis Mayr  ---
Comment on attachment 125576
  --> https://bugs.freedesktop.org/attachment.cgi?id=125576
Xorg.0.log VIVID - working

Xorg version is 7.5

-- 
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 97119] screen distortion under KDE when running without compositor

2016-08-23 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=97119

Johannes Hirte  changed:

   What|Removed |Added

 CC||johannes.hirte@datenkhaos.d
   ||e

--- Comment #3 from Johannes Hirte  ---
Created attachment 125982
  --> https://bugs.freedesktop.org/attachment.cgi?id=125982=edit
Xorg.0.log

Xorg.0.log when screen distortions started. Looks pretty normal to me. Are
there any debug options I need to enable?

-- 
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

Re: display/GFX issue with Ubuntu 16.04 not seen in 14.04

2016-08-23 Thread Adam Jackson 
On Tue, 2016-08-23 at 06:53 -0400, Jim Abernathy wrote:

> Can someone let me know where I can ask questions regarding problems 
> with X??  I thought this forum would be the place?

Most issues of this sort are more in the video driver than in X itself.
intel-...@lists.freedesktop.org is probably a more likely place to ask,
since you're using an Intel GPU.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: display/GFX issue with Ubuntu 16.04 not seen in 14.04

2016-08-23 Thread Christopher Barry 
On Tue, 23 Aug 2016 06:53:13 -0400
Jim Abernathy  wrote:

>On 08/19/2016 10:17 AM, Jim Abernathy wrote:
>> Not having much luck with the Distro forums on this issue so I
>> thought I'd ask for advice here.
>>
>> I've been running Ubuntu 14.04.5 for some time on Intel Core i5 GFX 
>> without any issues.  My display is HDMI from the PC to an Onkyo A/V 
>> receiver then to a Sony KDL-XBR6.
>>
>> When I try a fresh install of 16.04.1, I get a display that blanks
>> out for 3-5 seconds at random times depending on what is being
>> displayed at the time.  I also have small abouts of video noise that
>> is random horizontal lines about 1 pixel tall scattered through the
>> page.
>>
>> I noticed that 14.04.05 uses X server 1.17.2 and 16.04.1 uses 1.18.3.
>>
>> When I do the command xrandr --verbose I see some small differences 
>> between 14.04 and 16.04, but it's things like 2 digits displayed 
>> instead of 1.  i.e. 60.0 vs. 60.00. I'm only concerned with 1080P HD.
>>
>> I've tried this on different computers all with Intel GFX. same
>> results.
>>
>> This does not occur on other monitors or TVs.
>>
>> I'd blame it on Sony and Onkyo if they didn't work so well with 
>> Windows, all versions, and ubuntu all versions except 16.04.
>>
>> It's almost like the auto detection software in the newest version
>> of X is off just enough to make my display flaky.  Kind of like the
>> old analog CRT TVs that were sensitive to small tweaks to the
>> horizontal and vertical adjustments.
>>
>> Any help would be appreciated.
>>
>> Jim A
>>  
>
>Can someone let me know where I can ask questions regarding problems 
>with X??  I thought this forum would be the place?
>
>Jim A
>

Jim,

From the data above, I do not think it's possible to troubleshoot very
effectively. It also seems like (to me anyway) that you have a fairly
non-standard kind of configuration going on.

If I understand it, you have a media-center type PC with an integrated
Intel graphics card on an core i5 processor. Using an HDMI cable, you're
plugging into an Onkyo A/V receiver (you do not mention the model),
which in turn connects to a Sony KDL-XBR6 LCD TV.

What happens when you connect your PC to a the Sony directly or to
a normal PC LCD monitor? Does that work? 

Are you using an xorg configuration file, or are you allowing automatic
setup via kernel mode switching? If you a have config file(s), what
happens when you move them out of the way temporarily and allow
automatic config?

What's in your /var/log/Xorg.0.log?


People here help quite readily if they have data to act upon.

--
Regards,
Christopher Barry
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH 2/2] glamor: use write only for putimage in some cases (v2)

2016-08-23 Thread Dave Airlie 
From: Dave Airlie 

Ilia pointed out that xlock -mode wator is slow, this speeds it
up by avoiding the ReadPixels on every frame.

The current criteria for putimage is

a) ALU copy operation
b) planemask all set
c) region is contained inside pCompositeClip

v2: check for rgnIN (Peter Harris)

Signed-off-by: Dave Airlie 
---
 glamor/glamor_image.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c
index 3158749..055472e 100644
--- a/glamor/glamor_image.c
+++ b/glamor/glamor_image.c
@@ -88,7 +88,19 @@ static void
 glamor_put_image_bail(DrawablePtr drawable, GCPtr gc, int depth, int x, int y,
   int w, int h, int leftPad, int format, char *bits)
 {
-if (glamor_prepare_access_box(drawable, GLAMOR_ACCESS_RW, x, y, w, h))
+int access = GLAMOR_ACCESS_RW;
+
+if (gc->alu == GXcopy && glamor_pm_is_solid(gc->depth, gc->planemask)) {
+   BoxRec box;
+   box.x1 = x;
+   box.y1 = y;
+   box.x2 = x + w;
+   box.y2 = y + h;
+
+   if (RegionContainsRect(gc->pCompositeClip, ) == rgnIN)
+access = GLAMOR_ACCESS_WO;
+}
+if (glamor_prepare_access_box(drawable, access, x, y, w, h))
 fbPutImage(drawable, gc, depth, x, y, w, h, leftPad, format, bits);
 glamor_finish_access(drawable);
 }
-- 
2.5.5

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH v4 xserver 1/4] modesetting: make ms_do_pageflip generic for share with DRI2

2016-08-23 Thread Qiang Yu 
Signed-off-by: Qiang Yu 
Reviewed-by: Michel Dänzer 
---
 hw/xfree86/drivers/modesetting/present.c | 39 
 1 file changed, 25 insertions(+), 14 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/present.c 
b/hw/xfree86/drivers/modesetting/present.c
index 0093fb5..8b60c07 100644
--- a/hw/xfree86/drivers/modesetting/present.c
+++ b/hw/xfree86/drivers/modesetting/present.c
@@ -235,7 +235,7 @@ ms_present_flush(WindowPtr window)
  */
 struct ms_flipdata {
 ScreenPtr screen;
-struct ms_present_vblank_event *event;
+void *event;
 /* number of CRTC events referencing this */
 int flip_count;
 uint64_t fe_msc;
@@ -254,6 +254,12 @@ struct ms_crtc_pageflip {
 struct ms_flipdata *flipdata;
 };
 
+typedef void (*ms_pageflip_handler_proc)(uint64_t frame,
+ uint64_t usec,
+ void *data);
+
+typedef void (*ms_pageflip_abort_proc)(void *data);
+
 /**
  * Free an ms_crtc_pageflip.
  *
@@ -277,7 +283,7 @@ ms_present_flip_free(struct ms_crtc_pageflip *flip)
  * extension code telling it when that happened
  */
 static void
-ms_flip_handler(uint64_t msc, uint64_t ust, void *data)
+ms_present_flip_handler(uint64_t msc, uint64_t ust, void *data)
 {
 struct ms_crtc_pageflip *flip = data;
 ScreenPtr screen = flip->flipdata->screen;
@@ -331,7 +337,9 @@ ms_present_flip_abort(void *data)
 static Bool
 queue_flip_on_crtc(ScreenPtr screen, xf86CrtcPtr crtc,
struct ms_flipdata *flipdata,
-   int ref_crtc_vblank_pipe, uint32_t flags)
+   int ref_crtc_vblank_pipe, uint32_t flags,
+   ms_pageflip_handler_proc pageflip_handler,
+   ms_pageflip_abort_proc pageflip_abort)
 {
 ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
 modesettingPtr ms = modesettingPTR(scrn);
@@ -353,17 +361,12 @@ queue_flip_on_crtc(ScreenPtr screen, xf86CrtcPtr crtc,
 flip->on_reference_crtc = (drmmode_crtc->vblank_pipe == 
ref_crtc_vblank_pipe);
 flip->flipdata = flipdata;
 
-seq = ms_drm_queue_alloc(crtc, flip, ms_flip_handler, 
ms_present_flip_abort);
+seq = ms_drm_queue_alloc(crtc, flip, pageflip_handler, pageflip_abort);
 if (!seq) {
 free(flip);
 return FALSE;
 }
 
-DebugPresent(("\t\tms:fq %lld c %d -> %d seq %llu\n",
-  (long long) flipdata->event->event_id,
-  flipdata->flip_count, flipdata->flip_count + 1,
-  (long long) seq));
-
 /* take a reference on flipdata for use in flip */
 flipdata->flip_count++;
 
@@ -394,9 +397,11 @@ queue_flip_on_crtc(ScreenPtr screen, xf86CrtcPtr crtc,
 static Bool
 ms_do_pageflip(ScreenPtr screen,
PixmapPtr new_front,
-   struct ms_present_vblank_event *event,
+   void *event,
int ref_crtc_vblank_pipe,
-   Bool async)
+   Bool async,
+   ms_pageflip_handler_proc pageflip_handler,
+   ms_pageflip_abort_proc pageflip_abort)
 {
 #ifndef GLAMOR_HAS_GBM
 return FALSE;
@@ -470,7 +475,8 @@ ms_do_pageflip(ScreenPtr screen,
 
 if (!queue_flip_on_crtc(screen, crtc, flipdata,
 ref_crtc_vblank_pipe,
-flags)) {
+flags, pageflip_handler,
+pageflip_abort)) {
 goto error_undo;
 }
 }
@@ -588,8 +594,12 @@ ms_present_flip(RRCrtcPtr crtc,
 if (!event)
 return FALSE;
 
+DebugPresent(("\t\tms:pf %lld msc %llu\n",
+  (long long) event_id, (long long) target_msc));
+
 event->event_id = event_id;
-ret = ms_do_pageflip(screen, pixmap, event, drmmode_crtc->vblank_pipe, 
!sync_flip);
+ret = ms_do_pageflip(screen, pixmap, event, drmmode_crtc->vblank_pipe, 
!sync_flip,
+ ms_present_flip_handler, ms_present_flip_abort);
 if (!ret)
 xf86DrvMsg(scrn->scrnIndex, X_ERROR, "present flip failed\n");
 
@@ -615,7 +625,8 @@ ms_present_unflip(ScreenPtr screen, uint64_t event_id)
 event->event_id = event_id;
 
 if (ms_present_check_flip(NULL, screen->root, pixmap, TRUE) &&
-ms_do_pageflip(screen, pixmap, event, -1, FALSE)) {
+ms_do_pageflip(screen, pixmap, event, -1, FALSE,
+   ms_present_flip_handler, ms_present_flip_abort)) {
 return;
 }
 
-- 
2.7.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: display/GFX issue with Ubuntu 16.04 not seen in 14.04

2016-08-23 Thread Jim Abernathy 



On 08/19/2016 10:17 AM, Jim Abernathy wrote:
Not having much luck with the Distro forums on this issue so I thought 
I'd ask for advice here.


I've been running Ubuntu 14.04.5 for some time on Intel Core i5 GFX 
without any issues.  My display is HDMI from the PC to an Onkyo A/V 
receiver then to a Sony KDL-XBR6.


When I try a fresh install of 16.04.1, I get a display that blanks out 
for 3-5 seconds at random times depending on what is being displayed 
at the time.  I also have small abouts of video noise that is random 
horizontal lines about 1 pixel tall scattered through the page.


I noticed that 14.04.05 uses X server 1.17.2 and 16.04.1 uses 1.18.3.

When I do the command xrandr --verbose I see some small differences 
between 14.04 and 16.04, but it's things like 2 digits displayed 
instead of 1.  i.e. 60.0 vs. 60.00. I'm only concerned with 1080P HD.


I've tried this on different computers all with Intel GFX. same results.

This does not occur on other monitors or TVs.

I'd blame it on Sony and Onkyo if they didn't work so well with 
Windows, all versions, and ubuntu all versions except 16.04.


It's almost like the auto detection software in the newest version of 
X is off just enough to make my display flaky.  Kind of like the old 
analog CRT TVs that were sensitive to small tweaks to the horizontal 
and vertical adjustments.


Any help would be appreciated.

Jim A



Can someone let me know where I can ask questions regarding problems 
with X??  I thought this forum would be the place?


Jim A


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s


___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[PATCH v2 xserver 1/2] glamor: Add glamor_shareable_fd_from_pixmap()

2016-08-23 Thread Hans de Goede 
Add glamor_shareable_fd_from_pixmap function to get dma-buf fds suitable
for sharing across GPUs (not using GPU specific tiling).

This is necessary for the modesetting driver to correctly implement
the DRI2 SharePixmapBacking callback.

Signed-off-by: Hans de Goede 
---
 glamor/glamor.c | 20 
 glamor/glamor.h | 20 
 2 files changed, 40 insertions(+)

diff --git a/glamor/glamor.c b/glamor/glamor.c
index 5ba440c..903f6bd 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -821,6 +821,26 @@ glamor_fd_from_pixmap(ScreenPtr screen,
 return -1;
 }
 
+_X_EXPORT int
+glamor_shareable_fd_from_pixmap(ScreenPtr screen,
+PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
+{
+unsigned orig_usage_hint = pixmap->usage_hint;
+int ret;
+
+/*
+ * The actual difference between a sharable and non sharable buffer
+ * is decided 4 call levels deep in glamor_make_pixmap_exportable()
+ * based on pixmap->usage_hint == CREATE_PIXMAP_USAGE_SHARED
+ * 2 of those calls are also exported API, so we cannot just add a flag.
+ */
+pixmap->usage_hint = CREATE_PIXMAP_USAGE_SHARED;
+ret = glamor_fd_from_pixmap(screen, pixmap, stride, size);
+pixmap->usage_hint = orig_usage_hint;
+
+return ret;
+}
+
 int
 glamor_name_from_pixmap(PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
 {
diff --git a/glamor/glamor.h b/glamor/glamor.h
index e27033a..bdd2374 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -181,6 +181,26 @@ extern _X_EXPORT int glamor_fd_from_pixmap(ScreenPtr 
screen,
PixmapPtr pixmap,
CARD16 *stride, CARD32 *size);
 
+/* @glamor_shareable_fd_from_pixmap: Get a dma-buf fd suitable for sharing
+ *  with other GPUs from a pixmap.
+ *
+ * @screen: Current screen pointer.
+ * @pixmap: The pixmap from which we want the fd.
+ * @stride, @size: Pointers to fill the stride and size of the
+ *buffer associated to the fd.
+ *
+ * The returned fd will point to a buffer which is suitable for sharing
+ * across GPUs (not using GPU specific tiling).
+ * The pixmap and the buffer associated by the fd will share the same
+ * content.
+ * The pixmap's stride may be modified by this function.
+ * Returns the fd on success, -1 on error.
+ * */
+extern _X_EXPORT int glamor_shareable_fd_from_pixmap(ScreenPtr screen,
+ PixmapPtr pixmap,
+ CARD16 *stride,
+ CARD32 *size);
+
 /**
  * @glamor_name_from_pixmap: Gets a gem name from a pixmap.
  *
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH v2 xserver 2/2] modesetting: Fix msSharePixmapBacking returning a non-linear bo

2016-08-23 Thread Hans de Goede 
glamor_fd_from_pixmap() may return a tiled bo, which is not suitable
for sharing with another GPU as tiling usually is GPU specific.

Switch to glamor_shareable_fd_from_pixmap(), which always returns a
linear bo. This fixes mis-rendering when running the mode setting
driver on the master gpu in a dual-gpu setup and running an opengl
app with DRI_PRIME=1.

Signed-off-by: Hans de Goede 
---
 hw/xfree86/drivers/modesetting/driver.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
index 5ebb394..a8e83b2 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -1382,7 +1382,8 @@ msSharePixmapBacking(PixmapPtr ppix, ScreenPtr screen, 
void **handle)
 int ret;
 CARD16 stride;
 CARD32 size;
-ret = glamor_fd_from_pixmap(ppix->drawable.pScreen, ppix, , );
+ret = glamor_shareable_fd_from_pixmap(ppix->drawable.pScreen, ppix,
+  , );
 if (ret == -1)
 return FALSE;
 
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xfree86: print the module name together with the load failure message

2016-08-23 Thread Hans de Goede 

Hi,

On 23-08-16 06:47, Peter Hutterer wrote:

We're happily printing the error to the log but not which module caused it...
That's in the Xorg.log but that's at least one click away.

Signed-off-by: Peter Hutterer 


LGTM:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 hw/xfree86/loader/loadmod.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 702d4e7..8bf6836 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -626,9 +626,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo * 
data,
 else
 errtype = X_ERROR;
 xf86MsgVerb(errtype, 0,
-"module ABI major version (%d) doesn't"
+"%s: module ABI major version (%d) doesn't"
 " match the server's version (%d)\n",
-abimaj, vermaj);
+module, abimaj, vermaj);
 if (!(LoaderOptions & LDR_OPT_ABI_MISMATCH_NONFATAL))
 return FALSE;
 }
@@ -638,9 +638,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo * 
data,
 else
 errtype = X_ERROR;
 xf86MsgVerb(errtype, 0,
-"module ABI minor version (%d) is "
+"%s: module ABI minor version (%d) is "
 "newer than the server's version "
-"(%d)\n", abimin, vermin);
+"(%d)\n", module, abimin, vermin);
 if (!(LoaderOptions & LDR_OPT_ABI_MISMATCH_NONFATAL))
 return FALSE;
 }
@@ -651,24 +651,24 @@ CheckVersion(const char *module, XF86ModuleVersionInfo * 
data,
 if (req) {
 if (req->majorversion != MAJOR_UNSPEC) {
 if (data->majorversion != req->majorversion) {
-xf86MsgVerb(X_WARNING, 2, "module major version (%d) "
+xf86MsgVerb(X_WARNING, 2, "%s: module major version (%d) "
 "doesn't match required major version (%d)\n",
-data->majorversion, req->majorversion);
+module, data->majorversion, req->majorversion);
 return FALSE;
 }
 else if (req->minorversion != MINOR_UNSPEC) {
 if (data->minorversion < req->minorversion) {
-xf86MsgVerb(X_WARNING, 2, "module minor version (%d) "
+xf86MsgVerb(X_WARNING, 2, "%s: module minor version (%d) "
 "is less than the required minor version 
(%d)\n",
-data->minorversion, req->minorversion);
+module, data->minorversion, req->minorversion);
 return FALSE;
 }
 else if (data->minorversion == req->minorversion &&
  req->patchlevel != PATCH_UNSPEC) {
 if (data->patchlevel < req->patchlevel) {
-xf86MsgVerb(X_WARNING, 2, "module patch level (%d) "
+xf86MsgVerb(X_WARNING, 2, "%s: module patch level (%d) 
"
 "is less than the required patch level 
(%d)\n",
-data->patchlevel, req->patchlevel);
+module, data->patchlevel, req->patchlevel);
 return FALSE;
 }
 }
@@ -677,8 +677,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo * 
data,
 if (req->moduleclass) {
 if (!data->moduleclass ||
 strcmp(req->moduleclass, data->moduleclass)) {
-xf86MsgVerb(X_WARNING, 2, "Module class (%s) doesn't match "
+xf86MsgVerb(X_WARNING, 2, "%s: Module class (%s) doesn't match 
"
 "the required class (%s)\n",
+module,
 data->moduleclass ? data->moduleclass : "",
 req->moduleclass);
 return FALSE;
@@ -686,8 +687,9 @@ CheckVersion(const char *module, XF86ModuleVersionInfo * 
data,
 }
 else if (req->abiclass != ABI_CLASS_NONE) {
 if (!data->abiclass || strcmp(req->abiclass, data->abiclass)) {
-xf86MsgVerb(X_WARNING, 2, "ABI class (%s) doesn't match the "
+xf86MsgVerb(X_WARNING, 2, "%s: ABI class (%s) doesn't match the 
"
 "required ABI class (%s)\n",
+module,
 data->abiclass ? data->abiclass : "",
 req->abiclass);
 return FALSE;
@@ -702,15

Re: [PATCH xserver] glamor: Declare "pos" in the composite glyph GLSL 1.20 vertex shader

2016-08-23 Thread Michel Dänzer 
On 18/08/16 09:54 AM, Keith Packard wrote:
> Michel Dänzer  writes:
> 
>> From: Michel Dänzer 
>>
>> Fixes shader compile failure:
>>
>>  Failed to compile VS: 0:13(43): error: `pos' undeclared
>> 0:13(14): error: operands to arithmetic operators must be numeric
>> 0:13(13): error: operands to arithmetic operators must be numeric
>>
>>  Program source:
>> #define ATLAS_DIM_INV 0.0009765625
>> attribute vec2 primitive;
>> attribute vec2 source;
>> varying vec2 glyph_pos;
>> uniform vec2 fill_offset;
>> uniform vec2 fill_size_inv;
>> varying vec2 fill_pos;
>> uniform vec4 v_matrix;
>> void main() {
>>gl_Position.xy = primitive.xy * v_matrix.xz + v_matrix.yw;
>>gl_Position.zw = vec2(0.0,1.0);
>>glyph_pos = source.xy * ATLAS_DIM_INV;
>>fill_pos = (fill_offset + primitive.xy + pos) * fill_size_inv;
>> }
>>  (EE) Fatal server error:
>>  (EE) GLSL compile failure
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97300
>> Signed-off-by: Michel Dänzer 
> 
> Reviewed-by: Keith Packard 

Thanks, pushed (together with the glamor_copy_cpu_fbo bitplane support):

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #105956 updated using rev 
cba28d572ac799391beacd89d57e69d0d7ed70e7.
remote: I: patch #105827 updated using rev 
be334f42a198a25e817e6dab43dd0e30aa1cd4f8.
remote: I: 2 patch(es) updated to state Accepted.
To ssh+git://git.freedesktop.org/git/xorg/xserver
   6e5bec2..be334f4  master -> master


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver v3] glamor: Handle bitplane in glamor_copy_fbo_cpu

2016-08-23 Thread Michel Dänzer 
On 20/08/16 01:53 PM, Eric Anholt wrote:
> Michel Dänzer  writes:
> 
>> On 18/08/16 11:09 PM, Alex Deucher wrote:
>>> On Thu, Aug 18, 2016 at 5:42 AM, Michel Dänzer  wrote:
 From: Michel Dänzer 

 This can significantly speed up at least some CopyPlane cases, e.g.
 indirectly for stippled fills.

 v2:
 * Make temporary pixmap the same size as the destination pixmap
   (instead of the destination drawable size), and fix coordinate
   parameters passed to fbCopyXtoX and glamor_upload_boxes. Fixes
   incorrect rendering rendering with x11perf -copyplane* and crashes
   with the xscreensaver phosphor hack.
 v3:
 * Make the change a bit more compact and hopefully more readable by
   re-using the existing src_* locals in the bitplane case as well.

 Reported-by: Keith Raghubar 
 Signed-off-by: Michel Dänzer 
>>>
>>> Reviewed-by: Alex Deucher 
>>
>> Thanks, Alex.
>>
>>
>> Eric, what do you think about this patch? It can speed up clients
>> hitting this path by more than an order of magnitude, but it's not
>> exercised by XTS, and I currently don't have the bandwidth to change that.
> 
> Yeah, this is the example I was thinking of when I was saying "if we're
> going to be writing code to accelerate things, we'd better have tests
> for it", exemplified by the v2 changes.  However, I won't be getting
> around to writing the tests either, so we're in a bit of a bind.
> 
> I think, ultimately, getting glamor's performance up to expected matters
> the most, even if people suffer rendering failures along the way because
> we're bad at testing.  So,
> 
> Acked-by: Eric Anholt 

Thanks, pushed (together with the GLSL 1.20 glyph vertex shader fix):

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #105956 updated using rev 
cba28d572ac799391beacd89d57e69d0d7ed70e7.
remote: I: patch #105827 updated using rev 
be334f42a198a25e817e6dab43dd0e30aa1cd4f8.
remote: I: 2 patch(es) updated to state Accepted.
To ssh+git://git.freedesktop.org/git/xorg/xserver
   6e5bec2..be334f4  master -> master


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel