Re: [ANNOUNCE] xf86-video-amdgpu 1.3.0

2017-03-16 Thread Michel Dänzer 
On 17/03/17 11:32 AM, Zhang, Jerry wrote:
> Hi Michel,
> 
>> * Use libdrm_amdgpu functionality to determine the GPU marketing name,
>>   remove corresponding tables from this driver.
> 
> Could you elaborate it?
> I'd like to know how DDX(amdgpu) get the marketing name.

It uses libdrm_amdgpu's amdgpu_get_marketing_name API.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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: opengl and drm on a pi 3b?

2017-03-16 Thread Gene Heskett 
On Thursday 16 March 2017 14:18:53 you wrote:

> Hi
>
> As this isn't an "X" answer I've skipped the list.

And I've put it back so its in the archive FFR.

> What application 
> are you using?  Do you actually need X? do you actually need OpenGL?
>
Yes on both counts. The app, linuxcnc, has a nice gui control interface 
which includes a backplot of the machines motions while its carving up a 
block of metal to make something.  Screen refresh rate with what I am 
getting is about 15 frames a second, just noticeably slow. The numbers 
in the digital readout of the cutter location in 3d space, should just 
roll by, but they jump a decade or more in displayed value if the 
machine is moving at 5 inches a minute now.

> I ask these questions 'cos as it stands X + GL + HW Video is still a
> bit unsupported on the Pi.  If you just want video then junk X & OGL
> and your life will be a lot better.  X + HW decode can be made to work
> just about acceptably but it takes some effort, add OGL into the mix
> and whilst it should make life better by and large it doesn't (yet) as
> the mmal stacks don't play nice with the GL stacks.

Is there even movement afoot to fix this? If its fixed, the pi 3b can 
easily take over from the power hungry x86 boxes we generally use as the 
driving iron. Not an overnight takeover, but as the x86 boxes age out 
and people are becoming more conscious of the energy bills, it will 
happen.
>
> Regards
>
> JC
Thanks John.
>
> >Hello all, been a while since I rang your doorbell, greetings from
> > West Virginia;
> >
> >I am in the process of converting an old lathe to cnc, and using a pi
> > 3b as the driver.
> >
> >Doing some work on the configuration today, I got curious to see if
> > the features I was adding to the configuration were pushing the poor
> > pi to the point of exhaustion. Firing up htop, the various bits and
> > pieces that together make up linuxcnc, were a total of about 4 or 5%
> > of the cpu load.  Compton, the x compositor, was burning something
> > in the region of 165%, or a little over 1.5 of its 4 cores. It was
> > also a few megabytes into swap, so I rebooted it, after which
> > compton was only using perhaps 35% of one core.
> >
> >But my main reason for posting is to see if any progress is being
> > made on opengl and drm drivers for that bcm video the pi has.  The
> > display is just slow enough to be noticeable.  The machine its
> > driving can move at up to about 100 inches a minute, with bone
> > breaking force, so it would be a definite safety advantage if the
> > video could keep up with the machine in something resembling real
> > time.
> >
> >So what, if any, is the status of faster video drivers for the pi's
> > that use the bcm video?
> >
> >Thanks all.
> >
> >Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
___
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: [PATCH 1/4] xfree86: Don't bother probing -nv on Linux

2017-03-16 Thread Peter Hutterer 
On Thu, Mar 16, 2017 at 12:29:41PM +0200, Timo Aaltonen wrote:
> From: Timo Aaltonen 
> 
> For linux this driver is long obsolete now.  It may have some relevance
> on non-linux systems.
> 
> Signed-off-by: Timo Aaltonen 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  hw/xfree86/common/xf86pciBus.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
> index 9adfee5..66e576e 100644
> --- a/hw/xfree86/common/xf86pciBus.c
> +++ b/hw/xfree86/common/xf86pciBus.c
> @@ -1195,8 +1195,9 @@ xf86VideoPtrToDriverList(struct pci_device *dev,
>  
>  #ifdef __linux__
>  driverList[idx++] = "nouveau";
> -#endif
> +#else
>  driverList[idx++] = "nv";
> +#endif
>  break;
>  }
>  case 0x1106:
> -- 
> 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
> 
___
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 4/4] dix: Resize touch event history if the array is filled up

2017-03-16 Thread Peter Hutterer 
On Thu, Mar 16, 2017 at 12:29:44PM +0200, Timo Aaltonen wrote:
> From: Maarten Lankhorst 
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  dix/touch.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/dix/touch.c b/dix/touch.c
> index 37902bd..efc7ef9 100644
> --- a/dix/touch.c
> +++ b/dix/touch.c
> @@ -430,11 +430,25 @@ TouchEventHistoryPush(TouchPointInfoPtr ti, const 
> DeviceEvent *ev)
>  if (ev->flags & (TOUCH_CLIENT_ID | TOUCH_REPLAYING))
>  return;
>  
> +if (ti->history_elements == ti->history_size - 1) {
> +DeviceEvent *hist = NULL;
> +size_t sz = ti->history_size * 2;
> +
> +if (sz < 1) {
> +hist = realloc(ti->history, sz * sizeof(*hist));
> +
> +if (hist) {
> +ti->history = hist;
> +ti->history_size = sz;
> +memset([sz/2], 0, sizeof(*hist)*sz/2);

swap these around and memset first based on ti->history_elements and a
proper size-elements calculation. This avoids possible errors if history
size is ever an odd number (never going to happen, but...)

but do we even need the memset? if we're not copying the events correctly
and rely on zero memory then we'll have other problems.

Cheers,
   Peter


> +}
> +}
> +}
> +
>  ti->history[ti->history_elements++] = *ev;
> -/* FIXME: proper overflow fixes */
>  if (ti->history_elements > ti->history_size - 1) {
>  ti->history_elements = ti->history_size - 1;
> -DebugF("source device %d: history size %zu overflowing for touch 
> %u\n",
> +ErrorF("source device %d: history size %zu overflowing for touch 
> %u\n",
> ti->sourceid, ti->history_size, ti->client_id);
>  }
>  }
> -- 
> 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
> 
___
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: opengl and drm on a pi 3b?

2017-03-16 Thread Gene Heskett 
On Thursday 16 March 2017 13:55:44 Eric Anholt wrote:

> Gene Heskett  writes:
> > Hello all, been a while since I rang your doorbell, greetings from
> > West Virginia;
> >
> > I am in the process of converting an old lathe to cnc, and using a
> > pi 3b as the driver.
> >
> > Doing some work on the configuration today, I got curious to see if
> > the features I was adding to the configuration were pushing the poor
> > pi to the point of exhaustion. Firing up htop, the various bits and
> > pieces that together make up linuxcnc, were a total of about 4 or 5%
> > of the cpu load.  Compton, the x compositor, was burning something
> > in the region of 165%, or a little over 1.5 of its 4 cores. It was
> > also a few megabytes into swap, so I rebooted it, after which
> > compton was only using perhaps 35% of one core.
>
> That sounds like you're running your compositor in software rendering.

According to the Xorg.0.log, yes. But I've no idea how to fix that.

Thanks Eric.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
___
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: [ANNOUNCE] xf86-video-ati 7.9.0

2017-03-16 Thread Alex Deucher 
On Thu, Mar 16, 2017 at 2:25 PM, Adam Jackson  wrote:
> On Thu, 2017-03-16 at 10:59 +0100, poma wrote:
>
>> There are two applicable patches within Fedora:
>> https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/fix-dri-removal.patch?id=d5f48e7d5b6c
>
> An artifact of Fedora trying to not build DRI1. It's a fix in the wrong
> place, xserver should define the appropriate symbols if any DRI is
> built.
>
>> https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/radeon-6.12.2-lvds-default-modes.patch?id=9495e5b874d8
>
> Mostly a hack for LCDs that only claim one supported resolution and
> desktop environments too chicken to let you set arbitrary modes from
> the display control panel. Again, not really thrilled with the
> implementation of it, might be better solved in another place.

Do you have a specific test case this fixes?  The kernel driver always
adds the common modes to LVDS connectors, so they should be there.

Alex

>
>> Are these patches required, if so, care to explain?
>
> "Required", no. Nice to have, arguably.
>
> - 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
___
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: [PATCH xserver] glamor: Fix dashed line rendering.

2017-03-16 Thread Eric Anholt 
Eric Anholt  writes:

> We were binding the screen pixmap as the dash and sampling its alpha,
> which is usually just 1.0 (no dashing at all).
>
> Please cherry-pick this to active stable branches.

Pushed.  Thanks everyone!


signature.asc
Description: PGP 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: [ANNOUNCE] xf86-video-ati 7.9.0

2017-03-16 Thread Adam Jackson 
On Thu, 2017-03-16 at 10:59 +0100, poma wrote:

> There are two applicable patches within Fedora:
> https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/fix-dri-removal.patch?id=d5f48e7d5b6c

An artifact of Fedora trying to not build DRI1. It's a fix in the wrong
place, xserver should define the appropriate symbols if any DRI is
built.

> https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/radeon-6.12.2-lvds-default-modes.patch?id=9495e5b874d8

Mostly a hack for LCDs that only claim one supported resolution and
desktop environments too chicken to let you set arbitrary modes from
the display control panel. Again, not really thrilled with the
implementation of it, might be better solved in another place.

> Are these patches required, if so, care to explain?

"Required", no. Nice to have, arguably.

- 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: [PATCH xserver] sdksyms: Tighten up the symbols we add to the magic table

2017-03-16 Thread Adam Jackson 
On Thu, 2017-03-16 at 03:04 +, Emil Velikov wrote:

> Your earlier reply mentioned that [you think that] xf86-video-nested
> was a mistake without providing any justification why. It would be
> great to have some information what is broken and/or architecturally
> wrong with it or the other components mentioned just above.
> 
> IIRC the only issues [with Xorg] pointed out so far were a) memory
> consumption and b) providing a config file [via command line as
> non-root]. With the latter being resolved IIRC.

xfree86 assumes that there's actual silicon (or something very willing
to fake it, like vmwgfx or qxl) backing the screen, and that that
device is in some way bound to the system's console. The first X-under-
wayland driver was an xfree86 driver, and making that work involved
changing the xfree86 core in a bunch of places to _stop_ making those
assumptions (don't look at the pci bus, don't try to VT switch, get
input from this other source, etc.). Why bother undoing those
assumptions when you have a base class that makes none of them?

A vaguely appropriate analogy (if we're considering only OpenGL) would
be mesa/src/gallium. It's this whole other abstraction layer and maybe
it buys you some things, but mesa/src/mesa is the real GL core and one
does not need gallium to make a GL driver. You'd only use it if there
were any benefit.

And for hw/xfree86 there kind of isn't. Most of ScrnInfoRec (xfree86's
subclass of ScreenRec) is stuff that should reasonably be in the base
class. That it isn't is largely an artifact of the old regime, where
the X Consortium releases were actually pretty boring, and though
XFree86 was the thing most people ran there was not a lot of interest
or effort in reducing the diff between the two, or moving useful
functionality up to the dix layer.

Which means the real goal, in terms of code annihilationism, is to rely
on xfree86 less not more.

We already have three nested servers. Xephyr and Xnest legitimately
vary in their approach, one is an X11 proxy and the other owns its own
pixels. Xdmx is largely a clever variation on Xnest, and they should
converge in the future. What benefit does a nested driver for xfree86
add? Why increase dependence on a midlayer that shouldn't exist, and
whose value is in assumptions that don't apply?

Hence also my bafflement at people trying to build xfree86 on cygwin.
You don't town the display, you don't own the input devices, why try to
build a server that assumes those things? Darwin you could _maybe_
argue for, if >console at the login prompt still drops you to a text
login, but even that's a reach because you'd still need to write new
video and input drivers.

- ajax
___
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] glamor: Fix dashed line rendering.

2017-03-16 Thread Eric Anholt 
Keith Packard  writes:

> [ Unknown signature status ]
> Eric Anholt  writes:
>
>> We were binding the screen pixmap as the dash and sampling its alpha,
>> which is usually just 1.0 (no dashing at all).
>>
>> Please cherry-pick this to active stable branches.
>>
>> Signed-off-by: Eric Anholt 
>
> Thank you for finding this!
>
> Reviewed-by: Keith Packard 
>
> Now, can you explain why it ever did anything reasonable at all?

I'm sure that was just some pre-refactor version.  Sadly, xts doesn't
actually test dashes at all.


signature.asc
Description: PGP 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: Video tearing with modesetting driver and Intel Sandybridge graphics

2017-03-16 Thread Tino Mettler 
On Thu, Mar 16, 2017 at 11:54:46 +0900, Michel Dänzer wrote:
> Please provide the Xorg log file from the modesetting driver.

http://tikei.de/Xorg.1.log.txt

Regards,
Tino
___
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: [PATCH 1/4] xfree86: Don't bother probing -nv on Linux

2017-03-16 Thread Mark Kettenis 
> From: Timo Aaltonen 
> Date: Thu, 16 Mar 2017 12:29:41 +0200
> 
> From: Timo Aaltonen 
> 
> For linux this driver is long obsolete now.  It may have some relevance
> on non-linux systems.

Still somewhat relevant on OpenBSD indeed.  Diff makes sense to me.

Reviewed-by: Mark Kettenis 

> Signed-off-by: Timo Aaltonen 
> ---
>  hw/xfree86/common/xf86pciBus.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
> index 9adfee5..66e576e 100644
> --- a/hw/xfree86/common/xf86pciBus.c
> +++ b/hw/xfree86/common/xf86pciBus.c
> @@ -1195,8 +1195,9 @@ xf86VideoPtrToDriverList(struct pci_device *dev,
>  
>  #ifdef __linux__
>  driverList[idx++] = "nouveau";
> -#endif
> +#else
>  driverList[idx++] = "nv";
> +#endif
>  break;
>  }
>  case 0x1106:
> -- 
> 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
> 
> 
___
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] autobind GPUs to the screen

2017-03-16 Thread Timo Aaltonen 
On 06.12.2016 16:22, Hans de Goede wrote:
> 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 manually run
> "xrandr --setprovideroutputsource" before he can hookup an external
> monitor to his hybrid graphics laptop.
> 
> There is one problem with this patch, which is why it was not upstreamed
> before. What to do when a secondary GPU gets detected really is a policy
> decission (e.g. one may want to autobind PCI GPUs but not USB ones) and
> as such should be under control of the Desktop Environment.
> 
> Unconditionally adding autobinding support to the xserver will result
> in races between the DE dealing with the hotplug of a secondary GPU
> and the server itself dealing with it.
> 
> However we've waited for years for any Desktop Environments to actually
> start doing some sort of autoconfiguration of secondary GPUs and there
> is still not a single DE dealing with this, so I believe that it is
> time to upstream this now.
> 
> To avoid potential future problems if any DEs get support for doing
> secondary GPU configuration themselves, the new autobind functionality
> is made optional. Since no DEs currently support doing this themselves it
> is enabled by default. When DEs grow support for doing this themselves
> they can disable the servers autobinding through the servers cmdline or a
> xorg.conf snippet.
> 
> Signed-off-by: Dave Airlie 
> [hdego...@redhat.com: Make configurable, fix with nvidia, submit upstream]
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Make the default enabled instead of installing a xorg.conf
>  snippet which enables it unconditionally
> Changes in v3:
> -Handle GPUScreen autoconfig in randr/rrprovider.c, looking at
>  rrScrPriv->provider, rather then in hw/xfree86/modes/xf86Crtc.c
>  looking at xf86CrtcConfig->provider. This fixes the autoconfig not
>  working with the nvidia binary driver

Tested-by: Timo Aaltonen 

Ubuntu has had the old version for some years, and now this one works
with 1.19.x so would like to see it upstream.


-- 
t
___
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 1/4] xfree86: Don't bother probing -nv on Linux

2017-03-16 Thread Timo Aaltonen 
From: Timo Aaltonen 

For linux this driver is long obsolete now.  It may have some relevance
on non-linux systems.

Signed-off-by: Timo Aaltonen 
---
 hw/xfree86/common/xf86pciBus.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
index 9adfee5..66e576e 100644
--- a/hw/xfree86/common/xf86pciBus.c
+++ b/hw/xfree86/common/xf86pciBus.c
@@ -1195,8 +1195,9 @@ xf86VideoPtrToDriverList(struct pci_device *dev,
 
 #ifdef __linux__
 driverList[idx++] = "nouveau";
-#endif
+#else
 driverList[idx++] = "nv";
+#endif
 break;
 }
 case 0x1106:
-- 
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

[PATCH 3/4] xfree86: Do not bother registering xv/xvmc on gpu screens

2017-03-16 Thread Timo Aaltonen 
From: Maarten Lankhorst 

Signed-off-by: Maarten Lankhorst 
---
 hw/xfree86/common/xf86xv.c   |  2 +-
 hw/xfree86/common/xf86xvmc.c | 10 +++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/xfree86/common/xf86xv.c b/hw/xfree86/common/xf86xv.c
index d613d71..17f7214 100644
--- a/hw/xfree86/common/xf86xv.c
+++ b/hw/xfree86/common/xf86xv.c
@@ -230,7 +230,7 @@ xf86XVScreenInit(ScreenPtr pScreen, XF86VideoAdaptorPtr * 
adaptors, int num)
 ScrnInfoPtr pScrn;
 XF86XVScreenPtr ScreenPriv;
 
-if (num <= 0 || noXvExtension)
+if (num <= 0 || noXvExtension || pScreen->isGPU)
 return FALSE;
 
 if (Success != XvScreenInit(pScreen))
diff --git a/hw/xfree86/common/xf86xvmc.c b/hw/xfree86/common/xf86xvmc.c
index a0a94c7..9091a14 100644
--- a/hw/xfree86/common/xf86xvmc.c
+++ b/hw/xfree86/common/xf86xvmc.c
@@ -148,11 +148,15 @@ xf86XvMCScreenInit(ScreenPtr pScreen,
 {
 XvMCAdaptorPtr pAdapt;
 xf86XvMCScreenPtr pScreenPriv;
-XvScreenPtr pxvs = (XvScreenPtr) dixLookupPrivate(>devPrivates,
-  XF86XvScreenKey);
+XvScreenPtr pxvs;
 int i, j;
 
-if (noXvExtension)
+if (noXvExtension || pScreen->isGPU || !XF86XvScreenKey)
+return FALSE;
+
+pxvs = (XvScreenPtr) dixLookupPrivate(>devPrivates,
+  XF86XvScreenKey);
+if (!pxvs)
 return FALSE;
 
 if (!(pAdapt = xallocarray(num_adaptors, sizeof(XvMCAdaptorRec
-- 
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

[PATCH 4/4] dix: Resize touch event history if the array is filled up

2017-03-16 Thread Timo Aaltonen 
From: Maarten Lankhorst 

Signed-off-by: Maarten Lankhorst 
---
 dix/touch.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/dix/touch.c b/dix/touch.c
index 37902bd..efc7ef9 100644
--- a/dix/touch.c
+++ b/dix/touch.c
@@ -430,11 +430,25 @@ TouchEventHistoryPush(TouchPointInfoPtr ti, const 
DeviceEvent *ev)
 if (ev->flags & (TOUCH_CLIENT_ID | TOUCH_REPLAYING))
 return;
 
+if (ti->history_elements == ti->history_size - 1) {
+DeviceEvent *hist = NULL;
+size_t sz = ti->history_size * 2;
+
+if (sz < 1) {
+hist = realloc(ti->history, sz * sizeof(*hist));
+
+if (hist) {
+ti->history = hist;
+ti->history_size = sz;
+memset([sz/2], 0, sizeof(*hist)*sz/2);
+}
+}
+}
+
 ti->history[ti->history_elements++] = *ev;
-/* FIXME: proper overflow fixes */
 if (ti->history_elements > ti->history_size - 1) {
 ti->history_elements = ti->history_size - 1;
-DebugF("source device %d: history size %zu overflowing for touch %u\n",
+ErrorF("source device %d: history size %zu overflowing for touch %u\n",
ti->sourceid, ti->history_size, ti->client_id);
 }
 }
-- 
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

[PATCH 2/4] xfree86: Only set RR caps that are appropriate to main/gpu screen.

2017-03-16 Thread Timo Aaltonen 
From: Maarten Lankhorst 

Ubuntu bug https://launchpad.net/bugs/1277014

Signed-off-by: Maarten Lankhorst 
---
 hw/xfree86/modes/xf86RandR12.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/modes/xf86RandR12.c b/hw/xfree86/modes/xf86RandR12.c
index d834619..6d6977f 100644
--- a/hw/xfree86/modes/xf86RandR12.c
+++ b/hw/xfree86/modes/xf86RandR12.c
@@ -1671,10 +1671,16 @@ xf86RandR12CreateObjects12(ScreenPtr pScreen)
 }
 
 if (config->name) {
+uint32_t caps = pScrn->capabilities;
 config->randr_provider = RRProviderCreate(pScreen, config->name,
   strlen(config->name));
 
-RRProviderSetCapabilities(config->randr_provider, pScrn->capabilities);
+if (!pScreen->isGPU)
+caps &= RR_Capability_SinkOffload | RR_Capability_SourceOutput;
+else
+caps &= RR_Capability_SourceOffload | RR_Capability_SinkOutput;
+
+RRProviderSetCapabilities(config->randr_provider, caps);
 }
 
 return TRUE;
-- 
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

[PATCH xserver 0/4] Patches from Ubuntu

2017-03-16 Thread Timo Aaltonen 
Here are some patches that are actually upstreamable, and should have
been sent quite some time ago.

Maarten Lankhorst (3):
  Only set RR caps that are appropriate to main/gpu screen.
  Do not bother registering xv/xvmc on gpu screens
  Input: Resize touch event history if the array is filled up

Timo Aaltonen (1):
  Don't bother probing -nv on Linux

 dix/touch.c| 18 --
 hw/xfree86/common/xf86pciBus.c |  3 ++-
 hw/xfree86/common/xf86xv.c |  2 +-
 hw/xfree86/common/xf86xvmc.c   | 10 +++---
 hw/xfree86/modes/xf86RandR12.c |  8 +++-
 5 files changed, 33 insertions(+), 8 deletions(-)

-- 
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: [ANNOUNCE] xf86-video-ati 7.9.0

2017-03-16 Thread poma 
On 16.03.2017 09:16, Michel Dänzer wrote:
> 
> I'm pleased to announce the 7.9.0 release of xf86-video-ati, the Xorg
> driver for ATI/AMD Radeon GPUs supported by the radeon kernel driver.
> This release supports xserver versions 1.10-1.19.
> 
> NOTE for packagers: Please ship the new 10-radeon.conf file in the same
> package as radeon_drv.so.
> 
> Highlights:
> 
> * Allow TearFree to be toggled at runtime via an RandR output property
>   "TearFree". The xorg.conf option "TearFree" now controls the default
>   value of the output properties.
> * Use glamor by default for 2D acceleration with >= R600 and Xorg >=
>   1.18.3.
> * Ship 10-radeon.conf xorg.conf.d snippet for Xorg >= 1.16, so that the
>   radeon driver can be loaded automatically even when the ati wrapper
>   driver isn't installed.
> * Support loading the amdgpu driver from the ati wrapper driver.
> * Use DRM render nodes for DRI3 clients when available.
> 
> Plus many other improvements and fixes. Thanks to everybody who
> contributed to this release in any way!
> 

Hello!

There are two applicable patches within Fedora:
https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/fix-dri-removal.patch?id=d5f48e7d5b6c
https://src.fedoraproject.org/cgit/rpms/xorg-x11-drv-ati.git/commit/radeon-6.12.2-lvds-default-modes.patch?id=9495e5b874d8

Are these patches required, if so, care to explain?

Thanks

___
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

[ANNOUNCE] xf86-video-amdgpu 1.3.0

2017-03-16 Thread Michel Dänzer 

I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu, the Xorg
driver for AMD Radeon GPUs supported by the amdgpu kernel driver.
This release supports xserver versions 1.10-1.19.

Highlights:

* Allow TearFree to be toggled at runtime via an RandR output property
  "TearFree". The xorg.conf option "TearFree" now controls the default
  value of the output properties.
* Use libdrm_amdgpu functionality to determine the GPU marketing name,
  remove corresponding tables from this driver.
* Use DRM render nodes for DRI3 clients when available.

Plus many other improvements and fixes. Thanks to everybody who
contributed to this release in any way!


Emil Velikov (1):
  autogen.sh: use quoted string variables

Hans De Goede (1):
  amdgpu_probe: Do not close server managed drm fds

Jammy Zhou (1):
  Use render node for DRI3 if available

Michel Dänzer (44):
  Post-release version bump
  Move struct amdgpu_gpu_info out of amdgpu_get_tile_config
  Use family information from libdrm_amdgpu / kernel
  Stop using generated amdgpu_device_match
  Remove amdpciids.h
  Stop using AMDGPUPciChipsets
  Stop using AMDGPU(Unique)Chipsets
  Remove generated header files
  Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when available
  Make libdrm >= 2.4.72 requirement explicit
  Don't install Flush/EventCallback for GPU screens
  Add amdgpu_is_gpu_screen helper
  Take current scanout_id into account everywhere involved with TearFree
  Fix amdgpu_scanout_extents_intersect for GPU screens
  Call ValidateGC after ChangeClip in amdgpu_sync_scanout_pixmaps
  Call amdgpu_drm_abort_entry on failure to flip to a scanout pixmap
  Simplify drmmode_handle_uevents
  Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap
  Call drmmode_crtc_scanout_create in drmmode_crtc_shadow_allocate as well
  Fold drmmode_crtc_scanout_allocate into drmmode_crtc_scanout_create
  Handle rotation in the driver also with Xorg 1.12-1.18
  Fix flip event data leak if calloc or drmModeAddFB fails
  Don't destroy current FB if drmModeAddFB fails
  Factor out amdgpu_prime_dirty_to_crtc helper
  Factor out drmmode_crtc_scanout_update helper
  Allow toggling TearFree at runtime via output property
  Use drmmode_crtc_scanout_free in drmmode_fini
  present: Only call drmModeRmFB after setting modes for unflip
  present: Wait for GPU idle before setting modes for unflip
  present: Also flush before using a flip to unflip
  present: Use async flip for unflip if possible
  present: Flush before flipping
  Call drmmode_set_desired_modes from a WindowExposures hook
  Move DPMS check from amdgpu_scanout_do_update to amdgpu_scanout_flip
  Don't call amdgpu_glamor_flush in drmmode_copy_fb
  Don't use pScrn->is_gpu in AMDGPUCreateScreenResources_KMS
  Use local implementation of RegionDuplicate for older xserver
  Only define transform_region for XF86_CRTC_VERSION >= 4
  glamor: Don't flush in BlockHandler with Xorg >= 1.19
  Refactor amdgpu_kernel_close_fd helper
  glamor: Use glamor_finish when available
  Skip some initialization steps for GPU screens
  Pass TRUE to drmmode_set_desired_modes the first time for GPU screens
  Bump version for 1.3.0 release

Mihail Konev (1):
  autogen: add default patch prefix

Peter Hutterer (1):
  autogen.sh: use exec instead of waiting for configure to finish

jimqu (1):
  udev_monitor_receive_device() will block when hotplug monitor

git tag: xf86-video-amdgpu-1.3.0

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.bz2
MD5:  e2ee9e16ffbd45ebda68a7ff638a04f2  xf86-video-amdgpu-1.3.0.tar.bz2
SHA1: 7b89fe6e22e6739257c0f03c9f034c9c579a8bce  xf86-video-amdgpu-1.3.0.tar.bz2
SHA256: c1630f228938be949273f72b29ae70822dde064ad79c3ccb14d55f427e3f4e70  
xf86-video-amdgpu-1.3.0.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.gz
MD5:  c0c3d95fb2865008f1347bf9f38c0f44  xf86-video-amdgpu-1.3.0.tar.gz
SHA1: cc5766dd9a7851ef18f271898054f31e9cd2  xf86-video-amdgpu-1.3.0.tar.gz
SHA256: 05f4a1bbd3a0653551cb9871a554ec4b84c35d00a8fb101f772fc154253eb1e0  
xf86-video-amdgpu-1.3.0.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.gz.sig


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



signature.asc
Description: OpenPGP digital signature
___
xorg-announce mailing list
xorg-announce@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-announce

[ANNOUNCE] xf86-video-amdgpu 1.3.0

2017-03-16 Thread Michel Dänzer 

I'm pleased to announce the 1.3.0 release of xf86-video-amdgpu, the Xorg
driver for AMD Radeon GPUs supported by the amdgpu kernel driver.
This release supports xserver versions 1.10-1.19.

Highlights:

* Allow TearFree to be toggled at runtime via an RandR output property
  "TearFree". The xorg.conf option "TearFree" now controls the default
  value of the output properties.
* Use libdrm_amdgpu functionality to determine the GPU marketing name,
  remove corresponding tables from this driver.
* Use DRM render nodes for DRI3 clients when available.

Plus many other improvements and fixes. Thanks to everybody who
contributed to this release in any way!


Emil Velikov (1):
  autogen.sh: use quoted string variables

Hans De Goede (1):
  amdgpu_probe: Do not close server managed drm fds

Jammy Zhou (1):
  Use render node for DRI3 if available

Michel Dänzer (44):
  Post-release version bump
  Move struct amdgpu_gpu_info out of amdgpu_get_tile_config
  Use family information from libdrm_amdgpu / kernel
  Stop using generated amdgpu_device_match
  Remove amdpciids.h
  Stop using AMDGPUPciChipsets
  Stop using AMDGPU(Unique)Chipsets
  Remove generated header files
  Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when available
  Make libdrm >= 2.4.72 requirement explicit
  Don't install Flush/EventCallback for GPU screens
  Add amdgpu_is_gpu_screen helper
  Take current scanout_id into account everywhere involved with TearFree
  Fix amdgpu_scanout_extents_intersect for GPU screens
  Call ValidateGC after ChangeClip in amdgpu_sync_scanout_pixmaps
  Call amdgpu_drm_abort_entry on failure to flip to a scanout pixmap
  Simplify drmmode_handle_uevents
  Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap
  Call drmmode_crtc_scanout_create in drmmode_crtc_shadow_allocate as well
  Fold drmmode_crtc_scanout_allocate into drmmode_crtc_scanout_create
  Handle rotation in the driver also with Xorg 1.12-1.18
  Fix flip event data leak if calloc or drmModeAddFB fails
  Don't destroy current FB if drmModeAddFB fails
  Factor out amdgpu_prime_dirty_to_crtc helper
  Factor out drmmode_crtc_scanout_update helper
  Allow toggling TearFree at runtime via output property
  Use drmmode_crtc_scanout_free in drmmode_fini
  present: Only call drmModeRmFB after setting modes for unflip
  present: Wait for GPU idle before setting modes for unflip
  present: Also flush before using a flip to unflip
  present: Use async flip for unflip if possible
  present: Flush before flipping
  Call drmmode_set_desired_modes from a WindowExposures hook
  Move DPMS check from amdgpu_scanout_do_update to amdgpu_scanout_flip
  Don't call amdgpu_glamor_flush in drmmode_copy_fb
  Don't use pScrn->is_gpu in AMDGPUCreateScreenResources_KMS
  Use local implementation of RegionDuplicate for older xserver
  Only define transform_region for XF86_CRTC_VERSION >= 4
  glamor: Don't flush in BlockHandler with Xorg >= 1.19
  Refactor amdgpu_kernel_close_fd helper
  glamor: Use glamor_finish when available
  Skip some initialization steps for GPU screens
  Pass TRUE to drmmode_set_desired_modes the first time for GPU screens
  Bump version for 1.3.0 release

Mihail Konev (1):
  autogen: add default patch prefix

Peter Hutterer (1):
  autogen.sh: use exec instead of waiting for configure to finish

jimqu (1):
  udev_monitor_receive_device() will block when hotplug monitor

git tag: xf86-video-amdgpu-1.3.0

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.bz2
MD5:  e2ee9e16ffbd45ebda68a7ff638a04f2  xf86-video-amdgpu-1.3.0.tar.bz2
SHA1: 7b89fe6e22e6739257c0f03c9f034c9c579a8bce  xf86-video-amdgpu-1.3.0.tar.bz2
SHA256: c1630f228938be949273f72b29ae70822dde064ad79c3ccb14d55f427e3f4e70  
xf86-video-amdgpu-1.3.0.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.gz
MD5:  c0c3d95fb2865008f1347bf9f38c0f44  xf86-video-amdgpu-1.3.0.tar.gz
SHA1: cc5766dd9a7851ef18f271898054f31e9cd2  xf86-video-amdgpu-1.3.0.tar.gz
SHA256: 05f4a1bbd3a0653551cb9871a554ec4b84c35d00a8fb101f772fc154253eb1e0  
xf86-video-amdgpu-1.3.0.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-amdgpu-1.3.0.tar.gz.sig


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



signature.asc
Description: OpenPGP digital signature
___
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

[ANNOUNCE] xf86-video-ati 7.9.0

2017-03-16 Thread Michel Dänzer 

I'm pleased to announce the 7.9.0 release of xf86-video-ati, the Xorg
driver for ATI/AMD Radeon GPUs supported by the radeon kernel driver.
This release supports xserver versions 1.10-1.19.

NOTE for packagers: Please ship the new 10-radeon.conf file in the same
package as radeon_drv.so.

Highlights:

* Allow TearFree to be toggled at runtime via an RandR output property
  "TearFree". The xorg.conf option "TearFree" now controls the default
  value of the output properties.
* Use glamor by default for 2D acceleration with >= R600 and Xorg >=
  1.18.3.
* Ship 10-radeon.conf xorg.conf.d snippet for Xorg >= 1.16, so that the
  radeon driver can be loaded automatically even when the ati wrapper
  driver isn't installed.
* Support loading the amdgpu driver from the ati wrapper driver.
* Use DRM render nodes for DRI3 clients when available.

Plus many other improvements and fixes. Thanks to everybody who
contributed to this release in any way!


Emil Velikov (1):
  autogen.sh: use quoted string variables

Jammy Zhou (1):
  Use render node for DRI3 if available

Jochen Rollwagen (3):
  fix build for xserver < 1.13
  Calculate log base 2 in radeon.h based on clz for all platforms
  Fix build for XServer 1.13

Michel Dänzer (38):
  Post-release version bump
  Use DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags when available
  Enable glamor by default with >= R600 and Xorg >= 1.18.3
  Don't install Flush/EventCallback for GPU screens
  Pass fb_id into drmmode_page_flip_target_absolute/relative
  Add radeon_is_gpu_screen helper
  Take current scanout_id into account everywhere involved with TearFree
  Fix radeon_scanout_extents_intersect for GPU screens
  Call ValidateGC after ChangeClip in radeon_sync_scanout_pixmaps
  Call radeon_drm_abort_entry on failure to flip to a scanout pixmap
  Simplify drmmode_handle_uevents
  Pass pitch from drmmode_crtc_scanout_allocate to drmmode_create_bo_pixmap
  .editorconfig: src/ati.c only uses spaces for indentation
  ati: Support loading the amdgpu driver from the ati wrapper
  Add 10-radeon.conf xorg.conf.d snippet
  Enable tiling by default with glamor on PALM
  Don't handle Option "SwapbuffersWait" at all with glamor
  Fix flip event data leak if calloc or drmModeAddFB fails
  Don't destroy current FB if drmModeAddFB fails
  Factor out radeon_prime_dirty_to_crtc helper
  Factor out drmmode_crtc_scanout_update helper
  Allow toggling TearFree at runtime via output property
  Use drmmode_crtc_scanout_free in drmmode_fini
  present: Only call drmModeRmFB after setting modes for unflip
  present: Wait for screen pixmap BO idle before setting modes for unflip
  Call drmmode_crtc_scanout_create in drmmode_crtc_shadow_allocate as well
  Fold drmmode_crtc_scanout_allocate into drmmode_crtc_scanout_create
  Handle rotation in the driver also with Xorg 1.12-1.18
  present: Also flush before using a flip to unflip
  present: Use async flip for unflip if possible
  present: Flush before flipping
  Fix bogus indentation
  Call drmmode_set_desired_modes from a WindowExposures hook
  Move DPMS check from radeon_scanout_do_update to radeon_scanout_flip
  Don't call radeon_cs_flush_indirect & radeon_bo_wait in drmmode_copy_fb
  Skip some initialization steps for GPU screens
  Pass TRUE to drmmode_set_desired_modes the first time for GPU screens
  Bump version for 7.9.0 release

Mihail Konev (1):
  autogen: add default patch prefix

Peter Hutterer (1):
  autogen.sh: use exec instead of waiting for configure to finish

jimqu (1):
  udev_monitor_receive_device() will block when hotplug monitor

git tag: xf86-video-ati-7.9.0

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.bz2
MD5:  bf3dfdae23879bdc0c8a7b955572ad90  xf86-video-ati-7.9.0.tar.bz2
SHA1: 86ee6db1d7dcdeb1948aeb7965be8102c18be46b  xf86-video-ati-7.9.0.tar.bz2
SHA256: 3cad872e6330afb1707da11e4e959e6887ebe5bcd81854b4d2e496c52c059875  
xf86-video-ati-7.9.0.tar.bz2
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.bz2.sig

https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.gz
MD5:  4dd41ed1ad2f86f1b3e0b18e28f203fc  xf86-video-ati-7.9.0.tar.gz
SHA1: 70a8cee6da49738b7769f82e8130e9463825e3a1  xf86-video-ati-7.9.0.tar.gz
SHA256: e9580679e189be6edfd308ccc14588d1cac04e6b79a21f5c5061f4fef4191349  
xf86-video-ati-7.9.0.tar.gz
PGP:  
https://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-7.9.0.tar.gz.sig

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