Re: [ANNOUNCE] rendercheck 1.6

[Matt Turner]

On Wed, Apr 24, 2024 at 7:12 AM  wrote:
>
> In the commits, I note this:
>
> On Tue, Apr 23, 2024 at 03:53:39PM -0400, Matt Turner wrote:
> >[...]
> > Eric Anholt (10):
> >   [...]
> >   Remove the autotools build system.
>
> There are OSes that do not ship with Python. During an intermim
> period, couldn't we provide _both_ autotools and meson? in order to
> not wreak havoc releases for such OSes.

This is not really a core component of X by any measure. I don't have
any interest in restoring autotools (which was removed in the git repo
in 2017).

The upstream xserver and current releases of xwayland and mesa only
have meson build systems. I think y'all (OpenBSD?) probably need to
find another solution.

Re: [PATCH xf86-video-vmware] vmwgfx: Fix YV12 video corruption issue

[Matt Turner]

On Sun, Mar 28, 2021 at 10:57 AM Doug Brown  wrote:
>
> This fixes an issue I discovered with YV12 video that isn't a multiple
> of 8 pixels in width (after the round up to an even width value). Due to
> extra padding because the pitch doesn't match the width, the wrong data
> gets copied into the buffer.
>
> Example GStreamer command demonstrating the issue:
> gst-launch-1.0 videotestsrc ! \
> video/x-raw,format=YV12,width=782,height=482 ! xvimagesink
>
> Working width values:
> 775, 776, 783, 784
> Broken widths prior to this patch:
> 777-782
>
> Signed-off-by: Doug Brown 
> ---
> To test the change to vmwgfx_overlay.c, use a VMware VM with 3D
> acceleration turned off. To test the change to vmwgfx_tex_video.c, use a
> VMware VM with 3D acceleration turned on, or a VirtualBox VM with VMSVGA
> graphics and 3D acceleration turned on.
>
> I'm concerned that the fix in vmwgfx_overlay.c feels kind of dirty. The
> pitches array is getting passed onto the kernel driver, which I believe
> passes it onto the virtual hardware. I feel like it should be the
> responsibility of the virtual hardware to interpret the data correctly
> given that it is aware of the difference between width and pitch. But it
> doesn't seem to be paying attention to it. Is there somewhere else where
> the patch for that should go instead? Perhaps I should change the
> pitches array being sent out so it matches the data I send?
>
>  vmwgfx/vmwgfx_overlay.c   | 34 +-
>  vmwgfx/vmwgfx_tex_video.c | 19 +++
>  2 files changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/vmwgfx/vmwgfx_overlay.c b/vmwgfx/vmwgfx_overlay.c
> index 94d738c..e02c6fa 100644
> --- a/vmwgfx/vmwgfx_overlay.c
> +++ b/vmwgfx/vmwgfx_overlay.c
> @@ -478,7 +478,39 @@ vmw_video_port_play(ScrnInfoPtr pScrn, struct 
> vmwgfx_overlay_port *port,
>clipBoxes, pDraw);
>  }
>
> -memcpy(port->bufs[port->currBuf].data, buf, port->size);
> +switch (format) {
> +case FOURCC_YV12: {
> +unsigned char *ystart, *vstart, *ustart;
> +unsigned char *yp, *up, *vp;
> +int yidx, uidx, vidx;
> +int i, j;
> +yidx = uidx = vidx = 0;
> +ystart = port->bufs[port->currBuf].data;
> +vstart = ystart + w*h;
> +ustart = vstart + w*h/4;
> +yp = buf + port->offsets[0];
> +vp = buf + port->offsets[1];
> +up = buf + port->offsets[2];
> +for (i = 0; i < h; ++i) {
> +for (j = 0; j < w; ++j) {
> +ystart[yidx++] = yp[j];
> +}
> +yp += port->pitches[0];
> +if (i % 2 == 0) {
> +for (j = 0; j < w>>1; ++j) {
> +vstart[vidx++] = vp[j];
> +ustart[uidx++] = up[j];
> +}
> +vp += port->pitches[1];
> +up += port->pitches[2];
> +}
> +}
> +break;
> +}
> +default:
> +memcpy(port->bufs[port->currBuf].data, buf, port->size);
> +break;
> +}
>
>  memset(, 0, sizeof(arg));
>
> diff --git a/vmwgfx/vmwgfx_tex_video.c b/vmwgfx/vmwgfx_tex_video.c
> index acc2b56..0c79220 100644
> --- a/vmwgfx/vmwgfx_tex_video.c
> +++ b/vmwgfx/vmwgfx_tex_video.c
> @@ -603,7 +603,7 @@ copy_packed_data(ScrnInfoPtr pScrn,
>   int top,
>   unsigned short w, unsigned short h)
>  {
> -int i;
> +int i, j;
> struct xa_surface **yuv = port->yuv[port->current_set];
> char *ymap, *vmap, *umap;
> unsigned char _y1, _y2, u, v;
> @@ -634,9 +634,20 @@ copy_packed_data(ScrnInfoPtr pScrn,
>yp = buf + offsets[0];
>vp = buf + offsets[1];
>up = buf + offsets[2];
> -  memcpy(ymap, yp, w*h);
> -  memcpy(vmap, vp, w*h/4);
> -  memcpy(umap, up, w*h/4);
> +  for (i = 0; i < h; ++i) {
> +  for (j = 0; j < w; ++j) {
> +  ymap[yidx++] = yp[j];
> +  }
> +  yp += pitches[0];
> +  if (i % 2 == 0) {
> +  for (j = 0; j < w>>1; ++j) {
> +  vmap[vidx++] = vp[j];
> +  umap[uidx++] = up[j];
> +  }
> +  vp += pitches[1];
> +  up += pitches[2];
> +  }
> +  }
>break;
> }
> case FOURCC_UYVY:
> --

FWIW, we finally got them to allow merge requests on gitlab. If you
wouldn't mind and are still interested, please try making a merge
request at https://gitlab.freedesktop.org/xorg/driver/xf86-video-vmware

Re: Buildability of the Xorg drivers

[Matt Turner]

On Sun, Jan 30, 2022 at 4:16 PM Alan Coopersmith
 wrote:
> xf86-input-vmmouse
> xf86-video-vmware
>- do not allow merge requests

This has been an issue before, in conjunction with not even knowing
who the nominal maintainer was. E.g. someone submitted a patch almost
a year ago https://lists.x.org/archives/xorg-devel/2021-March/058688.html
after asking on IRC how to make a merge request and being told...
dunno, looks like you can't? Can we just turn on MRs for these
projects?

I see Zack recently joined the project on Gitlab and pushed to master,
so Cc'ing him.

> xf86-video-glint
>- Doesn't build due to the removal of ramdac drivers from Xorg:
>  https://gitlab.freedesktop.org/xorg/driver/xf86-video-glint/-/issues/1
>
> xf86-video-s3
>- Doesn't build due to the removal of ramdac drivers from Xorg, including
>  "IBM.h" and "TI.h"
>
> xf86-video-tga
>- Doesn't build due to the removal of ramdac drivers from Xorg, including
>  "BT.h"

Maybe we could make a libRAMDAC out of the removed files and these
drivers could link against it. I'll give that a shot when I have time.

Re: RFC: New libxcvt library

[Matt Turner]

On Fri, Mar 26, 2021 at 8:59 AM Olivier Fourdan  wrote:
>
> Hi all,
>
> Currently. the Xorg Xserver has its own implementation of the VESA CVT 
> standard timing modelines generator in `hw/xfree86/modes/xf86cvt.c`.
>
> That code is placed in its own source file alone because it is also being 
> used by the `cvt` utility.
>
> Because it's part of the Xorg DDX, Xwayland, which is another DDX also has a 
> copy of the same code in `hw/xwayland/xwayland-cvt.c`.
>
> Now with Xwayland being a standalone package, mutter which uses the cvt 
> utility at build time still needs to install `cvt` from Xorg to generate the 
> modes used in Wayland.
>
> Some time ago, discussing with Jonas Adahl on irc, we thought it would be a 
> good idea to have that code and utility part of its own standalone project, 
> to avoid the code duplication and possibly ease contributions.
>
> That was https://gitlab.freedesktop.org/xorg/xserver/-/issues/1142
>
> So I went ahead and did just that, called it “libxcvt” and placed in 
> https://gitlab.freedesktop.org/ofourdan/libxcvt
>
> I also made a merge request to use that code in the Xserver: 
> https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/637
>
> Can we consider moving “libxcvt” to the xorg/lib namespace in gitlab?

This is great and will help in packaging mutter and Wayland-only systems.

Can we please move this to the xorg/lib namespace and tag a release?
(Cc'ing daniels for the namespace move)

Thanks!
___
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] mi: sprite: SaveUnderCursor2

[Matt Turner]

On Tue, Mar 9, 2021 at 1:20 PM Walter Harms  wrote:
>
> hi Madhurkiran Harikrishnan,
> my experience is that readability reduced rapidly with indent-level.
> I would suggest:
>
>  if ( ! DevHasCursor(pDev) continue;
>
> pCursorInfo = GetSprite(pDev);
>
> if (!pCursorInfo) continue; // just to shrink the if ()
>
>
> // no braces needed
>  if ( pCursorInfo->isUp &&
>pCursorInfo->pScreen == pScreen)
>  miSpriteSaveUnderCursor(pDev, pScreen);

Not using braces here, with a line-wrapped conditional, is a bad idea.
Especially in nested control flow.
___
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: RFC: Minimum meson version for xserver 20

[Matt Turner]

On Mon, Mar 30, 2020 at 8:24 AM Adam Jackson  wrote:
>
> Does anyone have strong opinions on this? I would really like to bump
> to at least 0.49 for the position-independent executable support. If
> not that, 0.47 gives us 'feature' support for build options, which
> addresses the "should we enable this by default or not" question in a
> consistent way.

After a bunch of weeping and gnashing of teeth, I bumped Wayland's
dependency to meson >= 0.52.1, which is what is available in buster
backports.

I don't see a reason to pick anything older than that.
___
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: gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone  wrote:
>
> Hi Matt,
>
> On Thu, 27 Feb 2020 at 23:45, Matt Turner  wrote:
> > We're paying 75K USD for the bandwidth to transfer data from the
> > GitLab cloud instance. i.e., for viewing the https site, for
> > cloning/updating git repos, and for downloading CI artifacts/images to
> > the testing machines (AFAIU).
>
> I believe that in January, we had $2082 of network cost (almost
> entirely egress; ingress is basically free) and $1750 of cloud-storage
> cost (almost all of which was download). That's based on 16TB of
> cloud-storage (CI artifacts, container images, file uploads, Git LFS)
> egress and 17.9TB of other egress (the web service itself, repo
> activity). Projecting that out gives us roughly $45k of network
> activity alone, so it looks like this figure is based on a projected
> increase of ~50%.
>
> The actual compute capacity is closer to $1150/month.

Could we have the full GCP bill posted?
___
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: gitlab.fd.o financial situation and impact on services

[Matt Turner]

On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter  wrote:
>
> Hi all,
>
> You might have read the short take in the X.org board meeting minutes
> already, here's the long version.
>
> The good news: gitlab.fd.o has become very popular with our
> communities, and is used extensively. This especially includes all the
> CI integration. Modern development process and tooling, yay!
>
> The bad news: The cost in growth has also been tremendous, and it's
> breaking our bank account. With reasonable estimates for continued
> growth we're expecting hosting expenses totalling 75k USD this year,
> and 90k USD next year. With the current sponsors we've set up we can't
> sustain that. We estimate that hosting expenses for gitlab.fd.o
> without any of the CI features enabled would total 30k USD, which is
> within X.org's ability to support through various sponsorships, mostly
> through XDC.
>
> Note that X.org does no longer sponsor any CI runners themselves,
> we've stopped that. The huge additional expenses are all just in
> storing and serving build artifacts and images to outside CI runners
> sponsored by various companies. A related topic is that with the
> growth in fd.o it's becoming infeasible to maintain it all on
> volunteer admin time. X.org is therefore also looking for admin
> sponsorship, at least medium term.
>
> Assuming that we want cash flow reserves for one year of gitlab.fd.o
> (without CI support) and a trimmed XDC and assuming no sponsor payment
> meanwhile, we'd have to cut CI services somewhere between May and June
> this year. The board is of course working on acquiring sponsors, but
> filling a shortfall of this magnitude is neither easy nor quick work,
> and we therefore decided to give an early warning as soon as possible.
> Any help in finding sponsors for fd.o is very much appreciated.

Some clarification I got from Daniel in a private conversation, since
I was confused about what the money was paying for exactly:

We're paying 75K USD for the bandwidth to transfer data from the
GitLab cloud instance. i.e., for viewing the https site, for
cloning/updating git repos, and for downloading CI artifacts/images to
the testing machines (AFAIU).

I was not aware that we were being charged for anything wrt GitLab
hosting yet (and neither was anyone on my team at Intel that I've
asked). This... kind of needs to be communicated.

A consistent concern put forth when we were discussing switching to
GitLab and building CI was... how do we pay for it. It felt like that
concern was always handwaved away. I heard many times that if we
needed more runners that we could just ask Google to spin up a few
more. If we needed testing machines they'd be donated. No one
mentioned that all the while we were paying for bandwidth... Perhaps
people building the CI would make different decisions about its
structure if they knew it was going to wipe out the bank account.

What percentage of the bandwidth is consumed by transferring CI
images, etc? Wouldn't 75K USD would be enough to buy all the testing
machines we need and host them within Google or wherever so we don't
need to pay for huge amounts of bandwidth?

I understand that self-hosting was attractive so that we didn't find
ourselves on the SourceForge-equivalent hosting platform of 2022, but
is that risk real enough to justify spending 75K+ per year? If we were
hosted on gitlab.com or github.com, we wouldn't be paying for
transferring CI images to CI test machines, etc, would we?

So what do we do now? Have we painted ourselves into a corner?
___
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: libXt release

[Matt Turner]

On Tue, Jun 18, 2019 at 8:03 PM Thomas Dickey  wrote:
>
> On Tue, Jun 18, 2019 at 07:18:21AM -0400, Thomas Dickey wrote:
> > On Tue, Jun 18, 2019 at 05:37:40AM -0400, Thomas Dickey wrote:
> > > On Mon, Jun 17, 2019 at 10:08:21AM -0400, Matt Turner wrote:
> > > > On Mon, Jun 17, 2019 at 4:57 AM Thomas Dickey  wrote:
> > > > >
> > > > > On Sun, Jun 16, 2019 at 08:08:42PM -0400, Thomas Dickey wrote:
> > > > > > On Thu, Jun 13, 2019 at 03:43:04PM -0400, Thomas Dickey wrote:
> > > > > > > - Original Message -
> > > > > > > | From: "Matt Turner" 
> > > > > > > | To: "Thomas Dickey" 
> > > > > > > | Cc: "xorg-devel" 
> > > > > > > | Sent: Thursday, June 13, 2019 1:47:04 PM
> > > > > > > | Subject: libXt release
> > > > > > >
> > > > > > > | Hi Thomas,
> > > > > > > |
> > > > > > > | I'd like to do a tarball release of libXt since there are now 
> > > > > > > quite a
> > > > > > > | few commits since 1.1.5, released in 2015. Are you okay with me 
> > > > > > > making
> > > > > > > | a 1.2.0 release now, or is there anything else you would want 
> > > > > > > to get
> > > > > > > | into a new release?
> > > > > > >
> > > > > > > I've been working on some scripts to check for
> > > > > > > breakage in the specification document - might have some fixes 
> > > > > > > there.
> > > > > > >
> > > > > > > I'll review the current state on the weekend, to give better 
> > > > > > > advice.
> > > > > >
> > > > > > I think it's in good shape.  Because of the interface change (using
> > > > > > const), I was going to suggest that it should be 1.2.0
> > > > >
> > > > > I added a merge request for "1.2.0", which I'm testing,
> > > > > should be done tomorrow early (in case someone finds an issue).
> > > >
> > > > Thanks. Are you familiar with the Xorg release scripts [0]? There's a
> > > > wiki page at [1] that has instructions.
> > > >
> > > > If for any reason you have trouble making the release or uploading the
> > > > tarball, let me know and I'll be happy to handle it.
> > > >
> > > > [0] https://gitlab.freedesktop.org/xorg/util/modular/
> > >
> > > hmm - in a quick check, there's something amiss with the distcheck step
> > > because it's not picking up the right path to the makestrs utility
> > > (or failing to build it in parallel, etc).  That's with my Debian/testing
> > > machine.
>
> fixed that...
>
> But I don't have ssh access to the server to upload files.
>
> What is the next step?

Request an account and attach your GPG pubkey and SSH pubkey. It used
to be filed on Bugzilla, but according to [0] I guess you should use
gitlab. (I don't think anyone's really thought about this since the
gitlab transition)

[0] https://www.freedesktop.org/wiki/AccountRequests/
___
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: libXt release

[Matt Turner]

On Mon, Jun 17, 2019 at 4:57 AM Thomas Dickey  wrote:
>
> On Sun, Jun 16, 2019 at 08:08:42PM -0400, Thomas Dickey wrote:
> > On Thu, Jun 13, 2019 at 03:43:04PM -0400, Thomas Dickey wrote:
> > > - Original Message -
> > > | From: "Matt Turner" 
> > > | To: "Thomas Dickey" 
> > > | Cc: "xorg-devel" 
> > > | Sent: Thursday, June 13, 2019 1:47:04 PM
> > > | Subject: libXt release
> > >
> > > | Hi Thomas,
> > > |
> > > | I'd like to do a tarball release of libXt since there are now quite a
> > > | few commits since 1.1.5, released in 2015. Are you okay with me making
> > > | a 1.2.0 release now, or is there anything else you would want to get
> > > | into a new release?
> > >
> > > I've been working on some scripts to check for
> > > breakage in the specification document - might have some fixes there.
> > >
> > > I'll review the current state on the weekend, to give better advice.
> >
> > I think it's in good shape.  Because of the interface change (using
> > const), I was going to suggest that it should be 1.2.0
>
> I added a merge request for "1.2.0", which I'm testing,
> should be done tomorrow early (in case someone finds an issue).

Thanks. Are you familiar with the Xorg release scripts [0]? There's a
wiki page at [1] that has instructions.

If for any reason you have trouble making the release or uploading the
tarball, let me know and I'll be happy to handle it.

[0] https://gitlab.freedesktop.org/xorg/util/modular/
[1] https://www.x.org/wiki/Development/Documentation/ReleaseHOWTO/
___
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

libXt release

[Matt Turner]

Hi Thomas,

I'd like to do a tarball release of libXt since there are now quite a
few commits since 1.1.5, released in 2015. Are you okay with me making
a 1.2.0 release now, or is there anything else you would want to get
into a new release?

Thanks,
Matt
___
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 xf86-video-savage] Changing result parameter type for ScreenWakeupHandlerProcPtr

[Matt Turner]

On Thu, Jan 31, 2019 at 3:32 PM Kevin Brace  wrote:
>
> For ABI_VIDEODRV_VERSION >= 23, it was changed to int from unsigned
> long.
>
> Signed-off-by: Kevin Brace 
> ---
>  src/compat-api.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/compat-api.h b/src/compat-api.h
> index 44daea4..7cf29d0 100644
> --- a/src/compat-api.h
> +++ b/src/compat-api.h
> @@ -82,7 +82,7 @@

A little more context would have made this a bit easier to review. The
line immediately above this hunk is

#if ABI_VIDEODRV_VERSION >= SET_ABI_VERSION(23, 0)

>  #define BLOCKHANDLER_ARGS_DECL ScreenPtr arg, pointer pTimeout
>  #define BLOCKHANDLER_ARGS arg, pTimeout
>
> -#define WAKEUPHANDLER_ARGS_DECL ScreenPtr arg, unsigned long result
> +#define WAKEUPHANDLER_ARGS_DECL ScreenPtr arg, int result
>  #define WAKEUPHANDLER_ARGS arg, result

Reviewed-by: Matt Turner 

(and for the identical -tdfx patch as well)
___
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] result parameter for ScreenWakeupHandlerProcPtr should be unsigned long

[Matt Turner]

On Wed, Jan 9, 2019 at 10:03 AM Kevin Brace  wrote:
>
> Hi Dave,
>
> I do see what is going on, but was there a mistake in the X Server header 
> file when the ABI was changed?
> Who else uses ScreenWakeupHandlerProcPtr and does another device driver have 
> this issue?

Can we please try to keep discussion of one issue to one thread? This
is now the third separate thread on this list about this issue.

Also, please do not top quote.

As I said in the other thread, the result parameter is not even used
by -savage, so just change -savage and move on. I don't remember
finding any other drivers that used ScreenWakeupHandlerProcPtr, but
you can certainly confirm by cloning the repos and grepping. There's
no need to ask a question if you can easily answer it yourself
definitively.

I don't know that the s/unsigned long/int/ change (which was done in
xserver commit fb0802113b4c57819cba15d64baf79bf4148607e) was a mistake
-- seems more like a simplification while the ABI was being changes
anyway.
___
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: Will like to see some action on ScreenWakeupHandlerProcPtr related patch

[Matt Turner]

On Tue, Dec 18, 2018 at 3:16 PM Kevin Brace  wrote:
>
> Hi Alan,
>
> I am not asking to change the ABI.
> I just spotted an inconsistency in how ScreenWakeupHandlerProcPtr is defined 
> inside compat-api.h and scrnintstr.h.
> That appears the root of the problem.
> I consider this a bug.
> If I apply the patch to X Server's header file, the warning goes away.
>
> Proof:
>
> https://cgit.freedesktop.org/xorg/driver/xf86-video-savage/tree/src/compat-api.h?id=dce59663ecd846831724d6d7303ee813fa458a7d
>  (Line 85)
>
> https://cgit.freedesktop.org/xorg/xserver/tree/include/scrnintstr.h?h=server-1.19-branch=ebfb06b11955a6c32500b7086be912ab96b753a7
>  (Line 280 and 281)
>
>
> It appears that only xf86-video-savage is affected by this mismatch.

Why isn't the solution to change the definition of
WAKEUPHANDLER_ARGS_DECL in -savage to be

#define WAKEUPHANDLER_ARGS_DECL ScreenPtr arg, int result

SAVAGEWakeupHandler doesn't even use the result param, so... seems safe.
___
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: Will like to see some action on ScreenWakeupHandlerProcPtr related patch

[Matt Turner]

On Mon, Dec 17, 2018 at 6:09 PM Kevin Brace  wrote:
> I posted a small patch related to ScreenWakeupHandlerProcPtr several days ago.
>
> https://lists.x.org/archives/xorg-devel/2018-December/057793.html

No need to start an additional thread...
___
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: Will like to release xf86-video-mga Version 1.7 soon

[Matt Turner]

On Mon, Nov 26, 2018 at 11:30 AM Kevin Brace  wrote:
> If there are no objections, I will like to increment the version of 
> xf86-video-mga DDX to Version 1.7 (1.7.0) early next week.

Since the version numbers don't really have any meaning, would you
mind just picking xf86-video-mga-2.0.0? I ask because there are some
11 year old 1.9.99 and 1.9.100 release tags in the -mga repo that
confuse packaging software like Repology [1] and Euscan [2]. So if we
just picked 2.0.0 we'd no longer confuse those into thinking distros
are shipping old stuff.

[1] https://repology.org/metapackage/xdrv:mga/versions
[2] http://euscan.gentooexperimental.org/package/x11-drivers/xf86-video-mga/
___
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 v2] glamor: add support for NV12 in Xv

[Matt Turner]

On Tue, Sep 11, 2018 at 10:28 AM Julien Isorce  wrote:
>
> Useful when video decoders only output NV12. Currently
> glamor Xv only supports I420 and YV12.
>
> Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12.
>
> Test: xvinfo | grep NV12
> Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink
>
> v2: Combine the two texture2Ds on u_sampler.
>
> Signed-off-by: Julien Isorce 

I don't know the code well enough to give a R-b, but you fixed the one
thing I pointed out. Looks good to me.
___
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 3/3] glamor: add support for NV12 in Xv

[Matt Turner]

On Thu, Sep 6, 2018 at 3:40 PM Julien Isorce  wrote:
>
> Useful when video decoders only support NV12. Currently
> glamor Xv only supports I420 and YV12.
>
> Note that Intel's sna supports I420, YV12, YUY2, UYVY, NV12.
>
> Test: xvinfo | grep NV12
> Test: gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! xvimagesink
>
> Signed-off-by: Julien Isorce 
> ---
>  glamor/glamor_xv.c | 180 
> +
>  1 file changed, 155 insertions(+), 25 deletions(-)
>
> diff --git a/glamor/glamor_xv.c b/glamor/glamor_xv.c
> index 62fc4ff..5631293 100644
> --- a/glamor/glamor_xv.c
> +++ b/glamor/glamor_xv.c
> @@ -59,8 +59,40 @@ typedef struct tagREF_TRANSFORM {
>  #define RTFContrast(a)   (1.0 + ((a)*1.0)/1000.0)
>  #define RTFHue(a)   (((a)*3.1416)/1000.0)
>
> -static const glamor_facet glamor_facet_xv_planar = {
> -.name = "xv_planar",
> +static const glamor_facet glamor_facet_xv_planar_2 = {
> +.name = "xv_planar_2",
> +
> +.version = 120,
> +
> +.source_name = "v_texcoord0",
> +.vs_vars = ("attribute vec2 position;\n"
> +"attribute vec2 v_texcoord0;\n"
> +"varying vec2 tcs;\n"),
> +.vs_exec = (GLAMOR_POS(gl_Position, position)
> +"tcs = v_texcoord0;\n"),
> +
> +.fs_vars = ("uniform sampler2D y_sampler;\n"
> +"uniform sampler2D u_sampler;\n"
> +"uniform vec4 offsetyco;\n"
> +"uniform vec4 ucogamma;\n"
> +"uniform vec4 vco;\n"
> +"varying vec2 tcs;\n"),
> +.fs_exec = (
> +"float sample;\n"
> +"vec4 temp1;\n"
> +"sample = texture2D(y_sampler, tcs).w;\n"
> +"temp1.xyz = offsetyco.www * vec3(sample) + 
> offsetyco.xyz;\n"
> +"sample = texture2D(u_sampler, tcs).x;\n"
> +"temp1.xyz = ucogamma.xyz * vec3(sample) + 
> temp1.xyz;\n"
> +"sample = texture2D(u_sampler, tcs).y;\n"

Might as well combine the two texture2Ds on u_sampler. I expect most
GLSL compilers will be able to combine them into one operation, but
there's no point in leaving it to chance.
___
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 v2] meson: add option to disable selective werror

[Matt Turner]

On Thu, Aug 9, 2018 at 1:03 PM, Eric Anholt  wrote:
> "Marty E. Plummer"  writes:
>
>> Signed-off-by: Marty E. Plummer 
>
> We definitely want our -W flags.  Are you finding that one of the
> -Werror ones is throwing errors for you?  If so, let's fix that for
> everyone.

-Werror is fine for developers, but for distros it's a huge pain.

https://flameeyes.blog/2009/02/25/future-proof-your-code-dont-use-werror/

With every new version of GCC, not only does the set of warnings on by
default change but also its ability to detect warnings (i.e., the same
-Wflag is now more effective). Upgrading GCC already causes lots of
churn, and having to immediately deal with -Werror fall out just makes
this more difficult.
___
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: Inline xf86{Read, Write}Mmio{8, 16, 32} on alpha

[Matt Turner]

On Thu, Jun 7, 2018 at 10:55 AM, Adam Jackson  wrote:
> On Thu, 2018-06-07 at 09:31 -0700, Matt Turner wrote:
>> In commit 9db2af6f757e (xfree86: Remove xf86{Map,Unmap}VidMem) we
>> somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
>> function pointer indirection was intended to support dense vs sparse and
>> sparse support is now gone, we can just make the functions static inline
>> in compiler.h and avoid all of this.
>>
>> Bugzilla: https://bugs.gentoo.org/548906
>> Tested-by: Christopher May-Townsend 
>> Signed-off-by: Matt Turner 
>
> Reviewed-by: Adam Jackson 

Thanks, merged:

To ssh://git.freedesktop.org/git/xorg/xserver
   1993f147d..166ac294a  master -> master
___
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] xfree86: Inline xf86{Read, Write}Mmio{8, 16, 32} on alpha

[Matt Turner]

In commit 9db2af6f757e (xfree86: Remove xf86{Map,Unmap}VidMem) we
somehow stopped exporting xf86{Read,Write}Mmio{8,16,32}. Since the
function pointer indirection was intended to support dense vs sparse and
sparse support is now gone, we can just make the functions static inline
in compiler.h and avoid all of this.

Bugzilla: https://bugs.gentoo.org/548906
Tested-by: Christopher May-Townsend 
Signed-off-by: Matt Turner 
---
 configure.ac|  4 --
 hw/xfree86/common/compiler.h| 67 -
 hw/xfree86/os-support/bsd/Makefile.am   |  3 +-
 hw/xfree86/os-support/linux/Makefile.am | 12 --
 hw/xfree86/os-support/linux/lnx_video.c | 27 -
 hw/xfree86/os-support/meson.build   |  1 -
 6 files changed, 50 insertions(+), 64 deletions(-)

diff --git a/configure.ac b/configure.ac
index ddc47faa2..0075b6ace 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1908,9 +1908,6 @@ if test "x$XORG" = xyes; then
XORG_OS_SUBDIR="linux"
linux_acpi="no"
case $host_cpu in
- alpha*)
-   linux_alpha=yes
-   ;;
  i*86|amd64*|x86_64*|ia64*)
linux_acpi=$enable_linux_acpi
;;
@@ -2075,7 +2072,6 @@ AM_CONDITIONAL([XORG], [test "x$XORG" = xyes])
 AM_CONDITIONAL([XORG_BUS_PCI], [test "x$PCI" = xyes])
 AM_CONDITIONAL([XORG_BUS_BSDPCI], [test "x$xorg_bus_bsdpci" = xyes])
 AM_CONDITIONAL([XORG_BUS_SPARC], [test "x$xorg_bus_sparc" = xyes])
-AM_CONDITIONAL([LINUX_ALPHA], [test "x$linux_alpha" = xyes])
 AM_CONDITIONAL([LNXACPI], [test "x$linux_acpi" = xyes])
 AM_CONDITIONAL([LNXAPM], [test "x$linux_apm" = xyes])
 AM_CONDITIONAL([SOLARIS_VT], [test "x$solaris_vt" = xyes])
diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
index eea29dfb5..7144c6a27 100644
--- a/hw/xfree86/common/compiler.h
+++ b/hw/xfree86/common/compiler.h
@@ -986,33 +986,64 @@ inl(unsigned PORT_SIZE port)
 #endif
 
 #ifdef __alpha__
-/* entry points for Mmio memory access routines */
-extern _X_EXPORT int (*xf86ReadMmio8) (void *, unsigned long);
-extern _X_EXPORT int (*xf86ReadMmio16) (void *, unsigned long);
-extern _X_EXPORT int (*xf86ReadMmio32) (void *, unsigned long);
-extern _X_EXPORT void (*xf86WriteMmio8) (int, void *, unsigned long);
-extern _X_EXPORT void (*xf86WriteMmio16) (int, void *, unsigned long);
-extern _X_EXPORT void (*xf86WriteMmio32) (int, void *, unsigned long);
+static inline int
+xf86ReadMmio8(void *Base, unsigned long Offset)
+{
+mem_barrier();
+return *(CARD8 *) ((unsigned long) Base + (Offset));
+}
+
+static inline int
+xf86ReadMmio16(void *Base, unsigned long Offset)
+{
+mem_barrier();
+return *(CARD16 *) ((unsigned long) Base + (Offset));
+}
+
+static inline int
+xf86ReadMmio32(void *Base, unsigned long Offset)
+{
+mem_barrier();
+return *(CARD32 *) ((unsigned long) Base + (Offset));
+}
+
+static inline void
+xf86WriteMmio8(int Value, void *Base, unsigned long Offset)
+{
+write_mem_barrier();
+*(CARD8 *) ((unsigned long) Base + (Offset)) = Value;
+}
+
+static inline void
+xf86WriteMmio16(int Value, void *Base, unsigned long Offset)
+{
+write_mem_barrier();
+*(CARD16 *) ((unsigned long) Base + (Offset)) = Value;
+}
+
+static inline void
+xf86WriteMmio32(int Value, void *Base, unsigned long Offset)
+{
+write_mem_barrier();
+*(CARD32 *) ((unsigned long) Base + (Offset)) = Value;
+}
+
 extern _X_EXPORT void xf86SlowBCopyFromBus(unsigned char *, unsigned char *,
int);
 extern _X_EXPORT void xf86SlowBCopyToBus(unsigned char *, unsigned char *, 
int);
 
 /* Some macros to hide the system dependencies for MMIO accesses */
 /* Changed to kill noise generated by gcc's -Wcast-align */
-#define MMIO_IN8(base, offset) (*xf86ReadMmio8)(base, offset)
-#define MMIO_IN16(base, offset) (*xf86ReadMmio16)(base, offset)
-#define MMIO_IN32(base, offset) (*xf86ReadMmio32)(base, offset)
-
-#define MMIO_OUT32(base, offset, val) \
-do { \
-   write_mem_barrier(); \
-   *(volatile CARD32 *)(void *)(((CARD8*)(base)) + (offset)) = (val); \
-} while (0)
+#define MMIO_IN8(base, offset) xf86ReadMmio8(base, offset)
+#define MMIO_IN16(base, offset) xf86ReadMmio16(base, offset)
+#define MMIO_IN32(base, offset) xf86ReadMmio32(base, offset)
 
 #define MMIO_OUT8(base, offset, val) \
-(*xf86WriteMmio8)((CARD8)(val), base, offset)
+xf86WriteMmio8((CARD8)(val), base, offset)
 #define MMIO_OUT16(base, offset, val) \
-(*xf86WriteMmio16)((CARD16)(val), base, offset)
+xf86WriteMmio16((CARD16)(val), base, offset)
+#define MMIO_OUT32(base, offset, val) \
+xf86WriteMmio32((CARD32)(val), base, offset)
 
 #elif defined(__powerpc__) || defined(__sparc__)
  /*
diff --git a/hw/xfree86/os-support/

Re: [ANNOUNCE] xorg-server 1.20.0

[Matt Turner]

On Fri, May 11, 2018 at 2:28 PM, Thomas Klausner  wrote:
> xf86-video-intel-2.99.917:
>
> checking whether to include DRI1 support... no
> configure: error: DRI1 requested but prerequisites not found
> *** Error code 1

You probably just want to start using --disable-dri1 here.
___
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] randr: Account for panning and transforms when constraining the cursor

[Matt Turner]

From: Chris Wilson 

commit 56c90e29f04727c903bd0f084d23bf44eb1a0a11 [1.10.99.901]
Author: Adam Jackson 
Date:   Mon Nov 15 14:29:14 2010 -0500

randr: Add RRConstrainCursorHarder

introduced a regression as it ignored the effect of panning and
transforms upon the crtc bounds. The result was that the cursor would be
constrained to the visible area even though the panning arena was much
bigger, or the cursor was constrained to a region that did not even
match the visible area when the output was transformed or reflected.

This supercedes the hack introduced by
commit 1bf81af4a6be1113bcc3b940ab264d5c9e0f0c5d [1.12.99.904]
Author: Rui Matos 
Date:   Mon Jul 30 14:32:12 2012 -0400

xf86RandR12: Don't call ConstrainCursorHarder() if panning is enabled
which disabled the cursor constraints if a panning mode was active, but
did not fix the regression with arbitrary output transforms.

Signed-off-by: Chris Wilson 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=39949
Cc: Adam Jackson 
Cc: Rui Matos 
---
The bug's up to 78 comments and I'm getting pings from Gentoo users.

 randr/rrcrtc.c | 60 +-
 1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 338064f9f..d7d937e80 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -272,25 +272,34 @@ RRCrtcPendingProperties(RRCrtcPtr crtc)
 return FALSE;
 }
 
-static void
-crtc_bounds(RRCrtcPtr crtc, int *left, int *right, int *top, int *bottom)
+static Bool
+cursor_bounds(RRCrtcPtr crtc, int *left, int *right, int *top, int *bottom)
 {
-*left = crtc->x;
-*top = crtc->y;
+rrScrPriv(crtc->pScreen);
+BoxRec bounds;
 
-switch (crtc->rotation & 0xf) {
-case RR_Rotate_0:
-case RR_Rotate_180:
-default:
-*right = crtc->x + crtc->mode->mode.width;
-*bottom = crtc->y + crtc->mode->mode.height;
-return;
-case RR_Rotate_90:
-case RR_Rotate_270:
-*right = crtc->x + crtc->mode->mode.height;
-*bottom = crtc->y + crtc->mode->mode.width;
-return;
+if (crtc->mode == NULL)
+   return FALSE;
+
+memset(, 0, sizeof(bounds));
+if (pScrPriv->rrGetPanning)
+   pScrPriv->rrGetPanning(crtc->pScreen, crtc, NULL, , NULL);
+
+if (bounds.y2 <= bounds.y1 || bounds.x2 <= bounds.x1) {
+   bounds.x1 = 0;
+   bounds.y1 = 0;
+   bounds.x2 = crtc->mode->mode.width;
+   bounds.y2 = crtc->mode->mode.height;
 }
+
+pixman_f_transform_bounds(>f_transform, );
+
+*left = bounds.x1;
+*right = bounds.x2;
+*top = bounds.y1;
+*bottom = bounds.y2;
+
+return TRUE;
 }
 
 /* overlapping counts as adjacent */
@@ -302,8 +311,10 @@ crtcs_adjacent(const RRCrtcPtr a, const RRCrtcPtr b)
 int bl, br, bt, bb;
 int cl, cr, ct, cb; /* the overlap, if any */
 
-crtc_bounds(a, , , , );
-crtc_bounds(b, , , , );
+if (!cursor_bounds(a, , , , ))
+   return FALSE;
+if (!cursor_bounds(b, , , , ))
+   return FALSE;
 
 cl = max(al, bl);
 cr = min(ar, br);
@@ -321,7 +332,7 @@ mark_crtcs(rrScrPrivPtr pScrPriv, int *reachable, int cur)
 
 reachable[cur] = TRUE;
 for (i = 0; i < pScrPriv->numCrtcs; ++i) {
-if (reachable[i] || !pScrPriv->crtcs[i]->mode)
+if (reachable[i])
 continue;
 if (crtcs_adjacent(pScrPriv->crtcs[cur], pScrPriv->crtcs[i]))
 mark_crtcs(pScrPriv, reachable, i);
@@ -1811,10 +1822,8 @@ check_all_screen_crtcs(ScreenPtr pScreen, int *x, int *y)
 
 int left, right, top, bottom;
 
-if (!crtc->mode)
-continue;
-
-crtc_bounds(crtc, , , , );
+if (!cursor_bounds(crtc, , , , ))
+   continue;
 
 if ((*x >= left) && (*x < right) && (*y >= top) && (*y < bottom))
 return TRUE;
@@ -1834,10 +1843,9 @@ constrain_all_screen_crtcs(DeviceIntPtr pDev, ScreenPtr 
pScreen, int *x, int *y)
 int nx, ny;
 int left, right, top, bottom;
 
-if (!crtc->mode)
-continue;
+if (!cursor_bounds(crtc, , , , ))
+   continue;
 
-crtc_bounds(crtc, , , , );
 miPointerGetPosition(pDev, , );
 
 if ((nx >= left) && (nx < right) && (ny >= top) && (ny < bottom)) {
-- 
2.16.1

___
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] Xwayland: Don't notify RR of an unchanged size

[Matt Turner]

On Tue, Apr 17, 2018 at 3:44 PM, Preston Carpenter
 wrote:
> From: Timidger 

Do you mind using your real name?
___
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] xwayland: Fix build without glamor

[Matt Turner]

Thanks Olivier!

Reviewed-by: Matt Turner <matts...@gmail.com>
___
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] modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM

[Matt Turner]

Fixes a compilation error without Glamor.

Bugzilla: https://bugs.gentoo.org/653288
Signed-off-by: Matt Turner <matts...@gmail.com>
---
Unfortunately, there's more: Xwayland fails to link without Glamor.

 hw/xfree86/drivers/modesetting/drmmode_display.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 322ef050b..79e91f0f8 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -998,18 +998,18 @@ static Bool
 drmmode_create_bo(drmmode_ptr drmmode, drmmode_bo *bo,
   unsigned width, unsigned height, unsigned bpp)
 {
-uint32_t format;
-
-if (drmmode->scrn->depth == 30)
-format = GBM_FORMAT_ARGB2101010;
-else
-format = GBM_FORMAT_ARGB;
-
 bo->width = width;
 bo->height = height;
 
 #ifdef GLAMOR_HAS_GBM
 if (drmmode->glamor) {
+uint32_t format;
+
+if (drmmode->scrn->depth == 30)
+format = GBM_FORMAT_ARGB2101010;
+else
+format = GBM_FORMAT_ARGB;
+
 #ifdef GBM_BO_WITH_MODIFIERS
 uint32_t num_modifiers;
 uint64_t *modifiers = NULL;
-- 
2.16.1

___
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 bdftopcf] Depend on xproto and fsproto that are now used.

[Matt Turner]

On Sun, Dec 10, 2017 at 4:50 AM, Matthieu Herrb <matth...@herrb.eu> wrote:
> Signed-off-by: Matthieu Herrb <matth...@herrb.eu>
> ---

Yep, I came to the same conclusion in Gentoo.

Reviewed-by: Matt Turner <matts...@gmail.com>
___
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] configure.ac: unconditionally enable kdrive

[Matt Turner]

On Tue, Oct 24, 2017 at 10:27 AM, Matt Turner <matts...@gmail.com> wrote:
> Reviewed-by: Matt Turner <matts...@gmail.com>

Please merge. :)
___
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] configure.ac: unconditionally enable kdrive

[Matt Turner]

Reviewed-by: Matt Turner <matts...@gmail.com>
___
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: [Mesa-dev] XDC 2017 feedback

[Matt Turner]

On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark  wrote:
> If you had known of the khr dates, and brought it up in Feb (or really
> somewhat earlier, given that XDC is roughly same time each year +/-
> few weeks), that *might* have been early enough to move things.

That's unfair. It's part of the X.Org board's responsibilities to plan
conferences and that means being aware of potential conflicts. In
February, six of the eight members of the X.Org board worked for
companies with Khronos access (that's not including Keith who I
suspect has access as well).

I replied to the 2017-03-02 minutes and noted the conflict, but as you
say that was too late. Unfortunately that was the first time a date
was publicly announced, so I'm not really sure what could have been
done from outside the X.Org board.
___
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: [xrandr v2] Select NearestNeighbour filtering for pixel exact scaling

[Matt Turner]

Was there a reason this did not land?
___
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] On x86 targets, turn off SSE instructions for SlowBcopy

[Matt Turner]

On Sun, Jul 30, 2017 at 11:49 AM, Dimitry Andric  wrote:
> Some compilers (e.g. clang) will recognize the memcpy idiom in
> xf86SlowBcopy(), and optimize it into a loop using SSE instructions.
> This can cause "Illegal instruction" crashes under virtualization
> environments such as qemu/kvm.
>
> To prevent this, explicitly turn off SSE for SlowBcopy.c, when compiling
> for an x86 target.
>
> See also: https://bugs.freebsd.org/202643

Thanks. This is also reported in Gentoo's bug tracker as well:

Bugzilla: https://bugs.gentoo.org/570684
___
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 rendercheck 0/5] Convert to meson.

[Matt Turner]

On Fri, Mar 24, 2017 at 2:13 PM, Mark Kettenis  wrote:
>> From: Eric Anholt 
>> Date: Fri, 24 Mar 2017 13:17:45 -0700
>>
>> Having bitten off a bit more than I can chew in 3 days with the X
>> Server (hw/xfree86/sdksyms.c is the worst), I decided to take a quick
>> pass at converting a project that's my own fault.
>
> Seems I missed some discussion somewhere...
>
> While I understand your frustrations with autoconf, moving to build
> infrastructure that relies on tools like Python and Ninja would have
> serious consequences for the way we integrate X into OpenBSD.  We
> build the entire base OS, which includes X, with tools that are part
> of the base OS.  That would become pretty much impossible if various X
> projects go this way.

Yes, there's a thread on mesa-dev about switching to Meson that's
approaching 100 mails. A lot of it revolves the limitations OpenBSD
has placed on itself by putting Mesa (and X) into its core.
___
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] xkb: Correct type of XkbDfltAccessXOptions.

[Matt Turner]

Declared as unsigned short in xkb/xkbAccessX.c.

Signed-off-by: Matt Turner <matts...@gmail.com>
---
 xkb/xkbInit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xkb/xkbInit.c b/xkb/xkbInit.c
index 46016ab..9e45b4b 100644
--- a/xkb/xkbInit.c
+++ b/xkb/xkbInit.c
@@ -737,7 +737,7 @@ extern int XkbDfltRepeatInterval;
 extern unsigned short XkbDfltAccessXTimeout;
 extern unsigned int XkbDfltAccessXTimeoutMask;
 extern unsigned int XkbDfltAccessXFeedback;
-extern unsigned char XkbDfltAccessXOptions;
+extern unsigned short XkbDfltAccessXOptions;
 
 int
 XkbProcessArguments(int argc, char *argv[], int i)
@@ -798,7 +798,7 @@ XkbProcessArguments(int argc, char *argv[], int i)
 j++;
 }
 if (((i + 1) < argc) && (isdigit(argv[i + 1][0]))) {
-XkbDfltAccessXOptions = (unsigned char)
+XkbDfltAccessXOptions = (unsigned short)
 strtol(argv[++i], NULL, 16);
 j++;
 }
-- 
2.10.2

___
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 util-modular] release.sh: create a worktree structure that's out of reach of libtool

[Matt Turner]

On Wed, Mar 8, 2017 at 12:21 AM, Peter Hutterer
 wrote:
> +# libtool will search down to ../.. for install-sh and then just gess

typo: guess
___
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: xserver 1.19.2 call for patches

[Matt Turner]

These fix a regression 1.19 (https://bugs.freedesktop.org/show_bug.cgi?id=99358)

3eb964e25243056dd998f52d3b00171b71c89189 xfree86: Take input_lock()
for xf86ScreenCheckHWCursor
cfddd919cce4178baba07959e5e862d02e166522 xfree86: Take input lock for
xf86TransparentCursor
7198a6d4e74f684cb383b3e0f70dd2bae405e6e7 xfree86: Take the input lock
for xf86RecolorCursor
___
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] randr: Do not check the screen size bound for gpu screens

[Matt Turner]

On Wed, Aug 31, 2016 at 9:11 AM, Nikhil Mahale  wrote:
>>
>> OTOH this may indeed be a server bug, but your fix is not the right
>> one, I wonder why we are doing a RRSetScreenSize for slave GPU-s at
>> all. Since we already check that the Screen is big enough in
>> ProcRRSetCrtcConfig?
>
> We are looking for answer of this question, may be Dave or Ajax knows
> about this.
>
> Thanks,
> Nikhil Mahale

Someone pinged me to add this patch to Gentoo's xserver package, but
it'd be much preferred if the patch were upstream first. Ping for
perhaps ajax to take a look.
___
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] configure.ac: bump epoxy requirement to 1.2

[Matt Turner]

On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov  wrote:
> From: Emil Velikov 
>
> As pointed out in the ABI tracker[1], epoxy has gone through a few
> non-backwards compatible ABI changes, yet preserved the DSO name.
>
> Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
> - s/EGLDisplay */EGLDisplay/.
>
> To avoid unwanted/unexpected 'fun' behaviour, just bump the requirement.
> Version 1.2 has been released more than 2 years ago, in May 2014.
>
> [1] https://abi-laboratory.pro/tracker/timeline/libepoxy/
> Cc: Eric Anholt 
> Cc: Dave Airlie 
> Signed-off-by: Emil Velikov 
> ---
> We might want this in the stable branch(es)?
>
> Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
> it the canonical/upstream source] and was looking for your blessing.
>
> How is that going ? The state of the github repo looks tragic.

ajax and anholt were talking about epoxy's status at XDC. Cc'ing 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 1/3] xfree86/modes: Move gamma initialization to xf86RandR12Init12 v2

[Matt Turner]

On Tue, Jul 26, 2016 at 7:25 AM, walter harms  wrote:
>
>
> Am 26.07.2016 11:11, schrieb Michel Dänzer:
>> From: Michel Dänzer 
>>
>> RRCrtcGammaSetSize cannot be used yet in xf86InitialConfiguration,
>> because randr_crtc isn't allocated yet at that point, but a following
>> change will require RRCrtcGammaSetSize to be called from
>> xf86RandR12CrtcInitGamma.
>>
>> v2:
>> * Bail from xf86RandR12CrtcInitGamma if !crtc->funcs->gamma_set (Keith
>>   Packard)
>>
>> Signed-off-by: Michel Dänzer 
>> ---
>>  hw/xfree86/modes/xf86Crtc.c| 113 
>> 
>>  hw/xfree86/modes/xf86RandR12.c | 115 
>> -
>>  2 files changed, 114 insertions(+), 114 deletions(-)
>>
>> diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
>> index 4a13c13..966a168 100644
>> --- a/hw/xfree86/modes/xf86Crtc.c
>> +++ b/hw/xfree86/modes/xf86Crtc.c
>> @@ -2451,108 +2451,6 @@ xf86TargetUserpref(ScrnInfoPtr scrn, 
>> xf86CrtcConfigPtr config,
>>  return FALSE;
>>  }
>>
>> -static Bool
>> -xf86CrtcSetInitialGamma(xf86CrtcPtr crtc, float gamma_red, float 
>> gamma_green,
>> -float gamma_blue)
>> -{
>> -int i, size = 256;
>> -CARD16 *red, *green, *blue;
>> -
>> -red = xallocarray(size, 3 * sizeof(CARD16));
>> -green = red + size;
>> -blue = green + size;
>> -
>> -/* Only cause warning if user wanted gamma to be set. */
>> -if (!crtc->funcs->gamma_set &&
>> -(gamma_red != 1.0 || gamma_green != 1.0 || gamma_blue != 1.0)) {
>> -free(red);
>> -return FALSE;
>> -}
>> -else if (!crtc->funcs->gamma_set) {
>> -free(red);
>> -return TRUE;
>> -}
>> -
>> -/* At this early stage none of the randr-interface stuff is up.
>> - * So take the default gamma size for lack of something better.
>> - */
>> -for (i = 0; i < size; i++) {
>> -if (gamma_red == 1.0)
>> -red[i] = i << 8;
>> -else
>> -red[i] = (CARD16) (pow((double) i / (double) (size - 1),
>> -   1. / (double) gamma_red) * (double) 
>> (size -
>> -1) *
>> -   256);
>> -
>> -if (gamma_green == 1.0)
>> -green[i] = i << 8;
>> -else
>> -green[i] = (CARD16) (pow((double) i / (double) (size - 1),
>> - 1. / (double) gamma_green) *
>> - (double) (size - 1) * 256);
>> -
>> -if (gamma_blue == 1.0)
>> -blue[i] = i << 8;
>> -else
>> -blue[i] = (CARD16) (pow((double) i / (double) (size - 1),
>> -1. / (double) gamma_blue) * (double) 
>> (size -
>> -  
>> 1) *
>> -256);
>> -}
>> -
>> -/* Default size is 256, so anything else is failure. */
>> -if (size != crtc->gamma_size) {
>> -free(red);
>> -return FALSE;
>> -}
>> -
>> -crtc->gamma_size = size;
>> -memcpy(crtc->gamma_red, red, crtc->gamma_size * sizeof(CARD16));
>> -memcpy(crtc->gamma_green, green, crtc->gamma_size * sizeof(CARD16));
>> -memcpy(crtc->gamma_blue, blue, crtc->gamma_size * sizeof(CARD16));
>> -
>> -/* Do not set gamma now, delay until the crtc is activated. */
>> -
>> -free(red);
>> -
>> -return TRUE;
>> -}
>> -
>> -static Bool
>> -xf86OutputSetInitialGamma(xf86OutputPtr output)
>> -{
>> -XF86ConfMonitorPtr mon = output->conf_monitor;
>> -float gamma_red = 1.0, gamma_green = 1.0, gamma_blue = 1.0;
>> -
>> -if (!mon)
>> -return TRUE;
>> -
>> -if (!output->crtc)
>> -return FALSE;
>> -
>> -/* Get configured values, where they exist. */
>> -if (mon->mon_gamma_red >= GAMMA_MIN && mon->mon_gamma_red <= GAMMA_MAX)
>> -gamma_red = mon->mon_gamma_red;
>> -
>> -if (mon->mon_gamma_green >= GAMMA_MIN && mon->mon_gamma_green <= 
>> GAMMA_MAX)
>> -gamma_green = mon->mon_gamma_green;
>> -
>> -if (mon->mon_gamma_blue >= GAMMA_MIN && mon->mon_gamma_blue <= 
>> GAMMA_MAX)
>> -gamma_blue = mon->mon_gamma_blue;
>> -
>> -/* This avoids setting gamma 1.0 in case another cloned output on this 
>> crtc has a specific gamma. */
>> -if (gamma_red != 1.0 || gamma_green != 1.0 || gamma_blue != 1.0) {
>> -xf86DrvMsg(output->scrn->scrnIndex, X_INFO,
>> -   "Output %s wants gamma correction (%.1f, %.1f, %.1f)\n",
>> -   output->name, gamma_red, gamma_green, gamma_blue);
>> -return xf86CrtcSetInitialGamma(output->crtc, gamma_red, gamma_green,
>> -   gamma_blue);
>> -}
>> -else
>> -return TRUE;
>> -}
>> -
>>  /**
>>   * 

Re: [PATCH xserver 5/8] xquartz/glx: Error out for MakeContextCurrent(draw != read)

[Matt Turner]

On Mon, Mar 21, 2016 at 1:29 PM, Adam Jackson  wrote:
> CGL doesn't have a way to express this directly, unlike EGL WGL and GLX.
> It might be implementable, but it's never actually worked, and it's a
> fairly niche feature so we're better off throwing an error if someone
> attempts it.
>
> Signed-off-by: Adam Jackson 
> ---
>  hw/xquartz/GL/indirect.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/hw/xquartz/GL/indirect.c b/hw/xquartz/GL/indirect.c
> index 54c9073..c0648c4 100644
> --- a/hw/xquartz/GL/indirect.c
> +++ b/hw/xquartz/GL/indirect.c
> @@ -387,6 +387,9 @@ __glXAquaContextMakeCurrent(__GLXcontext *baseContext)
>
>  GLAQUA_DEBUG_MSG("glAquaMakeCurrent (ctx 0x%p)\n", baseContext);
>
> +if (context->base.drawPriv !+ context->base.readPriv)

I'm not sure how that parses. Should be !=
___
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:makedepend] Use do { ... } while(0) idiom to make debug() macro safer

[Matt Turner]

On Sat, Mar 12, 2016 at 10:24 AM, walter harms  wrote:
>
>
> Am 12.03.2016 19:15, schrieb Alan Coopersmith:
>> Cleans up several -Wempty-body warnings from gcc 5.3
>>
>> Signed-off-by: Alan Coopersmith 
>> ---
>>  def.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/def.h b/def.h
>> index 1930cde..59670a9 100644
>> --- a/def.h
>> +++ b/def.h
>> @@ -82,9 +82,9 @@ extern int  _debugmask;
>>   * 3 show #include SYMBOL
>>   * 4-6   unused
>>   */
>> -#define debug(level,arg) { if (_debugmask & (1 << level)) warning arg; }
>> +#define debug(level,arg) do { if (_debugmask & (1 << level)) warning arg; } 
>> while(0)
>>  #else
>> -#define  debug(level,arg) /**/
>> +#define  debug(level,arg) do { /**/ } while (0)
>>  #endif /* DEBUG */
>>
>>  typedef  unsigned char boolean;
>
>
>  #definedebug(level,arg)   while(0)
>
> should be sufficient (not tested)

Maybe, but that sure looks strange to my eye, while the do { ... }
while(0) pattern is well recognized.
___
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 6/8] ephyr: Create 3.3 core profile context if possible (v3)

[Matt Turner]

On Mon, Jan 18, 2016 at 11:02 PM, Dave Airlie  wrote:
> From: Keith Packard 
>
> On desktop GL, Ask for a 3.3 core profile context if that's available,
> otherwise create a generic context.
>
> v2: tell glamor the profile is a core one.
> v2.1: add/use GL version defines
> v3: let glamor work out core itself
>
> Signed-off-by: Keith Packard 
> Signed-off-by: Dave Airlie 
> ---
>  hw/kdrive/ephyr/ephyr_glamor_glx.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/hw/kdrive/ephyr/ephyr_glamor_glx.c 
> b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> index 30c5245..b9fe8d1 100644
> --- a/hw/kdrive/ephyr/ephyr_glamor_glx.c
> +++ b/hw/kdrive/ephyr/ephyr_glamor_glx.c
> @@ -41,6 +41,10 @@
>  #include "os.h"
>  #include 
>
> +/* until we need geometry shaders GL3.1 should suffice. */
> +/* Xephyr has it's own copy of this for build reasons */
> +#define GLAMOR_GL_CORE_VER_MAJOR 3
> +#define GLAMOR_GL_CORE_VER_MINOR 1
>  /** @{
>   *
>   * global state for Xephyr with glamor.
> @@ -319,7 +323,19 @@ ephyr_glamor_glx_screen_init(xcb_window_t win)
> "GLX_EXT_create_context_es2_profile\n");
>  }
>  } else {
> -ctx = glXCreateContext(dpy, visual_info, NULL, True);
> +static const int context_attribs[] = {
> +GLX_CONTEXT_PROFILE_MASK_ARB,
> +GLX_CONTEXT_CORE_PROFILE_BIT_ARB,
> +GLX_CONTEXT_MAJOR_VERSION_ARB,
> +GLAMOR_GL_CORE_VER_MAJOR,
> +GLX_CONTEXT_MINOR_VERSION_ARB,
> +GLAMOR_GL_CORE_VER_MINOR,
> +0,
> +};
> +ctx = glXCreateContextAttribsARB(dpy, fb_config, NULL, True,
> + context_attribs);
> +if (!ctx)
> +ctx = glXCreateContext(dpy, visual_info, NULL, True);
>  }
>  if (ctx == NULL)
>  FatalError("glXCreateContext failed\n");
> --

GL 3.2 adds profiles -- they're not available in GL 3.1. The
GLX_ARB_create_context_profile spec says:

 If the requested OpenGL version is less than 3.2,
 GLX_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
 of the context is determined solely by the requested version.


If you simply ask for 3.1, you may get GL_ARB_compatibility... The spec says:

If version 3.1 is requested, the context returned may implement
any of the following versions:

  * Version 3.1. The GL_ARB_compatibility extension may or may not
be implemented, as determined by the implementation.
  * The core profile of version 3.2 or greater.

It's probably a safe bet that no driver we care about glamor running
on will implement GL_ARB_compatibility, so maybe asking for 3.1 is the
best thing to do. The lack of profiles in 3.1 is a real pain in the
ass.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libXfont] Convert to non-recursive build.

[Matt Turner]

---
Because two Makefiles are better than ten.

 Makefile.am  | 114 ++-
 configure.ac |  10 +
 src/FreeType/Makefile.am |  15 ---
 src/Makefile.am  |  68 
 src/bitmap/Makefile.am   |  29 
 src/builtins/Makefile.am |  17 ---
 src/dummy.c  |   0
 src/fc/Makefile.am   |  16 ---
 src/fontfile/Makefile.am |  29 
 src/stubs/Makefile.am|  10 -
 src/util/Makefile.am |  18 
 11 files changed, 114 insertions(+), 212 deletions(-)
 delete mode 100644 src/FreeType/Makefile.am
 delete mode 100644 src/Makefile.am
 delete mode 100644 src/bitmap/Makefile.am
 delete mode 100644 src/builtins/Makefile.am
 delete mode 100644 src/dummy.c
 delete mode 100644 src/fc/Makefile.am
 delete mode 100644 src/fontfile/Makefile.am
 delete mode 100644 src/stubs/Makefile.am
 delete mode 100644 src/util/Makefile.am

diff --git a/Makefile.am b/Makefile.am
index 43ccd34..86870bb 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,7 +19,7 @@
 #  TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 #  PERFORMANCE OF THIS SOFTWARE.
 
-SUBDIRS=doc src
+SUBDIRS=doc
 
 libXfontincludedir = $(includedir)/X11/fonts
 libXfontinclude_HEADERS = \
@@ -48,6 +48,118 @@ nodist_libXfontinclude_HEADERS = \
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = xfont2.pc
 
+lib_LTLIBRARIES = libXfont2.la
+
+AM_CPPFLAGS = -I${top_srcdir}/include
+AM_CFLAGS = $(XFONT_CFLAGS) $(OS_CFLAGS) $(CWARNFLAGS)
+
+libXfont2_la_SOURCES = \
+   src/stubs/atom.c\
+   src/stubs/libxfontstubs.c   \
+   src/util/fontaccel.c\
+   src/util/fontnames.c\
+   src/util/fontutil.c \
+   src/util/fontxlfd.c \
+   src/util/format.c   \
+   src/util/miscutil.c \
+   src/util/patcache.c \
+   src/util/private.c  \
+   src/util/utilbitmap.c
+
+libXfont2_la_LDFLAGS = -version-number 2:0:0 -no-undefined
+
+libXfont2_la_LIBADD = $(Z_LIBS) $(MATH_LIBS) $(XFONT_LIBS)
+
+if XFONT_FONTFILE
+libXfont2_la_SOURCES +=\
+   src/fontfile/bitsource.c\
+   src/fontfile/bufio.c\
+   src/fontfile/decompress.c   \
+   src/fontfile/defaults.c \
+   src/fontfile/dirfile.c  \
+   src/fontfile/fileio.c   \
+   src/fontfile/filewr.c   \
+   src/fontfile/fontdir.c  \
+   src/fontfile/fontencc.c \
+   src/fontfile/fontfile.c \
+   src/fontfile/fontscale.c\
+   src/fontfile/gunzip.c   \
+   src/fontfile/register.c \
+   src/fontfile/renderers.c\
+   src/fontfile/catalogue.c
+
+if X_BZIP2_FONT_COMPRESSION
+libXfont2_la_SOURCES += src/fontfile/bunzip2.c
+endif
+endif
+
+if XFONT_FREETYPE
+AM_CFLAGS += $(FREETYPE_CFLAGS)
+
+libXfont2_la_LIBADD += $(FREETYPE_LIBS)
+libXfont2_la_SOURCES +=\
+   src/FreeType/ft.h   \
+   src/FreeType/ftfuncs.h  \
+   src/FreeType/xttcap.h   \
+   src/FreeType/ftenc.c\
+   src/FreeType/ftfuncs.c  \
+   src/FreeType/fttools.c  \
+   src/FreeType/xttcap.c
+endif
+
+if XFONT_BITMAP
+libXfont2_la_SOURCES +=\
+   src/bitmap/bitmap.c \
+   src/bitmap/bitmapfunc.c \
+   src/bitmap/bitmaputil.c \
+   src/bitmap/bitscale.c   \
+   src/bitmap/fontink.c
+
+if XFONT_BDFFORMAT
+libXfont2_la_SOURCES +=\
+   src/bitmap/bdfread.c\
+   src/bitmap/bdfutils.c
+endif
+
+if XFONT_PCF_OR_BUILTIN
+libXfont2_la_SOURCES += src/bitmap/pcfread.c
+endif
+
+if XFONT_PCFFORMAT
+libXfont2_la_SOURCES += src/bitmap/pcfwrite.c
+endif
+
+if XFONT_SNFFORMAT
+libXfont2_la_SOURCES +=\
+   src/bitmap/snfread.c\
+   src/bitmap/snfstr.h
+endif
+endif
+
+if XFONT_BUILTINS
+libXfont2_la_SOURCES +=\
+   src/builtins/builtin.h  \
+   src/builtins/dir.c  \
+   src/builtins/file.c \
+   src/builtins/fonts.c\
+   src/builtins/fpe.c  \
+   src/builtins/render.c
+endif
+
+if XFONT_FC
+libXfont2_la_SOURCES +=\
+   src/fc/fsconvert.c  \
+   src/fc/fserve.c \
+   src/fc/fserve.h \
+   src/fc/fservestr.h  \
+   src/fc/fsio.c   \
+   src/fc/fsio.h   \
+   src/fc/fslibos.h\
+   src/fc/fstrans.c
+endif
+
+EXTRA_DIST = src/builtins/buildfont
+
 MAINTAINERCLEANFILES = ChangeLog INSTALL
 
 .PHONY: ChangeLog INSTALL
diff --git a/configure.ac b/configure.ac
index 

Re: CC_CHECK_FLAGS_APPEND (was Re: libXfont: Changes to 'master')

[Matt Turner]

On Tue, Dec 8, 2015 at 10:51 PM, Jeremy Huddleston Sequoia
 wrote:
> ./configure: line 19194: syntax error near unexpected token `with_cflags,'
> ./configure: line 19194: `  CC_CHECK_FLAGS_APPEND(with_cflags, CFLAGS, \'
>
> From what I can tell, CC_CHECK_FLAGS_APPEND comes from glib.  Can we please 
> not add a dependency on glib for this?

Given the addition of

+AC_CONFIG_MACRO_DIR([m4])

I think Keith just forgot to git add a file.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Pass -P to the preprocessor when generating filenames for the manpage.

[Matt Turner]

On Wed, Oct 7, 2015 at 7:46 AM, Aurelien Jarno <aurel...@aurel32.net> wrote:
> On 2015-09-30 15:16, Matt Turner wrote:
>> On Wed, Sep 9, 2015 at 2:44 PM, Aurelien Jarno <aurel...@aurel32.net> wrote:
>> > From: Stefan Dirsch <sndir...@suse.de>
>> >
>> > Fixes build with GCC 5. Patch by Richard Biener <rguent...@suse.com>
>> > ---
>> >  man/Makefile.am | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > sessreg doesn't build with GCC 5 (BZ90615), due to new line markers in
>> > the preprocessor output. GCC documentation advise to use -P [1]. This is
>> > the solution chosen by freebsd [2], suse [3] or suggested in the debian
>> > bug log [4]. Note that it is supported by at least clang and oracle
>> > studio.
>> >
>> > In order to avoid every for distribution to implement this solution in
>> > a different way, I have just taken the suse patch and I am sending it
>> > with this mail. I hope it could be applied that way.
>> >
>> > [1] http://gcc.gnu.org/gcc-5/porting_to.html
>> > [2] https://reviews.freebsd.org/rP382986
>> > [3] http://lists.opensuse.org/opensuse-commit/2015-02/msg01337.html
>> > [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778176#36
>> >
>> >
>> > diff --git a/man/Makefile.am b/man/Makefile.am
>> > index 665ace5..2e5f146 100644
>> > --- a/man/Makefile.am
>> > +++ b/man/Makefile.am
>> > @@ -9,7 +9,7 @@ SUFFIXES = .$(APP_MAN_SUFFIX) .man
>> >
>> >  AM_CPPFLAGS = -I$(top_builddir) -I$(top_srcdir)
>> >  filenames.sed: filenames.sed.c
>> > -   $(AM_V_GEN)$(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
>> > +   $(AM_V_GEN)$(CPP) -P $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
>> > $(AM_CPPFLAGS) $(CPPFLAGS) $(srcdir)/filenames.sed.c | \
>> > $(SED) -n -e '/s|__/ p' -e '/^\/__/ p' > $@
>> >
>> > --
>>
>> This works for me. I'm happy to see it committed (and I can do that
>> for you if you want -- just let me know).
>
> Given nobody seems to have complain about this for some days, I would
> indeed appreciate if you can commit it. Thanks!

Sure. Pushed as commit 93f5d5abf.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Stop accessing the attribute array using the attribute name enum.

[Matt Turner]

On Tue, Oct 6, 2015 at 3:43 AM, Thomas Klausner  wrote:
> The whole SMI_VideoAttributes array looks quite strange to me.
>
> static XF86AttributeRec SMI_VideoAttributes[2] = {
> {XvSettable | XvGettable,0,   255, XV_BRIGHTNESS_NAME},
> {XvSettable | XvGettable, 0x00,  0xFF, XV_COLORKEY_NAME},
> };
>
> but it is accessed using these defines as indices:
>
> #define XV_ENCODING 0
> #define XV_BRIGHTNESS   1
> #define XV_CAPTURE_BRIGHTNESS   2
> #define XV_CONTRAST 3
> #define XV_SATURATION   4
> #define XV_HUE  5
> #define XV_COLORKEY 6
> #define XV_INTERLACED   7
>
> However, all of this code including the CLAMP has been this way since
>
> commit 78af703cb019a60cc93843efcd4889ccb15abd13
> Author: Kaleb Keithley 
> Date:   Fri Nov 14 16:48:55 2003 +
>
> Initial revision
>
>
> I agree that this CLAMP call should go, perhaps just ifdefed out with
> a comment. Not sure what the tradition for this is with xorg.

Just delete it -- the history and the deleted code will still be in git.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Stop accessing the attribute array using the attribute name enum.

[Matt Turner]

On Tue, Sep 29, 2015 at 9:02 PM, Robert Ancell
 wrote:
> The array has only two elements but the clamping code was assuming it 
> contained
> all the elements in order. This means no clamping is now done but at least it
> wont read off the end of the array.
>
> Signed-off-by: Robert Ancell 
> ---

You should sent patches as [PATCH:project] these days, otherwise if
people don't recognize the names of the modified source files they
won't know where to apply it.

Cc'ing Thomas and Connor who have sent/reviewed patches for
xf86-video-siliconmotion recently.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Pass -P to the preprocessor when generating filenames for the manpage.

[Matt Turner]

On Wed, Sep 9, 2015 at 2:44 PM, Aurelien Jarno  wrote:
> From: Stefan Dirsch 
>
> Fixes build with GCC 5. Patch by Richard Biener 
> ---
>  man/Makefile.am | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> sessreg doesn't build with GCC 5 (BZ90615), due to new line markers in
> the preprocessor output. GCC documentation advise to use -P [1]. This is
> the solution chosen by freebsd [2], suse [3] or suggested in the debian
> bug log [4]. Note that it is supported by at least clang and oracle
> studio.
>
> In order to avoid every for distribution to implement this solution in
> a different way, I have just taken the suse patch and I am sending it
> with this mail. I hope it could be applied that way.
>
> [1] http://gcc.gnu.org/gcc-5/porting_to.html
> [2] https://reviews.freebsd.org/rP382986
> [3] http://lists.opensuse.org/opensuse-commit/2015-02/msg01337.html
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778176#36
>
>
> diff --git a/man/Makefile.am b/man/Makefile.am
> index 665ace5..2e5f146 100644
> --- a/man/Makefile.am
> +++ b/man/Makefile.am
> @@ -9,7 +9,7 @@ SUFFIXES = .$(APP_MAN_SUFFIX) .man
>
>  AM_CPPFLAGS = -I$(top_builddir) -I$(top_srcdir)
>  filenames.sed: filenames.sed.c
> -   $(AM_V_GEN)$(CPP) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
> +   $(AM_V_GEN)$(CPP) -P $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \
> $(AM_CPPFLAGS) $(CPPFLAGS) $(srcdir)/filenames.sed.c | \
> $(SED) -n -e '/s|__/ p' -e '/^\/__/ p' > $@
>
> --

This works for me. I'm happy to see it committed (and I can do that
for you if you want -- just let me know).
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXfont] Eliminate calls back to X server or font server functions by name

[Matt Turner]

On Wed, Sep 2, 2015 at 12:15 AM, Keith Packard  wrote:
> This eliminates the weak symbol adventures and makes all of the calls
> back to the X server or Font server go through a table of functions
> instead, clarifying the required API.
>
> As this is a rather major change to the API for the library, it now
> installs itself as libXfont_2 instead of libXfont, and the package
> config file is now xfont_2.pc.
>
> All of the installed headers remain the same as the original library;
> there's now a new include file, libxfont_2.h, which defines the X
> server and Font server interfaces.
>
> Signed-off-by: Keith Packard 
> ---

Some whitespace fixes and a problem with an #include noted below.

>  Makefile.am|   7 +-
>  configure.ac   |   4 +-
>  include/X11/fonts/bufio.h  |   2 +-
>  include/X11/fonts/fontmisc.h   |   2 +-
>  include/X11/fonts/libxfont_2.h |  81 +
>  include/libxfontint.h  |  90 +++
>  src/FreeType/ft.h  |   2 -
>  src/FreeType/ftenc.c   |   1 +
>  src/FreeType/ftfuncs.c |   1 +
>  src/FreeType/fttools.c |   1 +
>  src/FreeType/xttcap.c  |   1 +
>  src/Makefile.am|   8 +-
>  src/bitmap/bdfread.c   |   1 +
>  src/bitmap/bdfutils.c  |   1 +
>  src/bitmap/bitmap.c|   1 +
>  src/bitmap/bitmapfunc.c|   1 +
>  src/bitmap/bitmaputil.c|   1 +
>  src/bitmap/bitscale.c  |   4 +-
>  src/bitmap/fontink.c   |   1 +
>  src/bitmap/pcfread.c   |   1 +
>  src/bitmap/pcfwrite.c  |   7 +-
>  src/bitmap/snfread.c   |   1 +
>  src/builtins/dir.c |   1 +
>  src/builtins/file.c|   1 +
>  src/builtins/fonts.c   |   1 +
>  src/builtins/fpe.c |  36 +++---
>  src/builtins/render.c  |   1 +
>  src/fc/fsconvert.c |   1 +
>  src/fc/fserve.c|  44 
>  src/fc/fserve.h|   9 --
>  src/fc/fsio.c  |   1 +
>  src/fc/fstrans.c   |   2 +
>  src/fontfile/bitsource.c   |   1 +
>  src/fontfile/bufio.c   |   3 +-
>  src/fontfile/bunzip2.c |   1 +
>  src/fontfile/catalogue.c   |  36 +++---
>  src/fontfile/decompress.c  |   1 +
>  src/fontfile/defaults.c|   1 +
>  src/fontfile/dirfile.c |   1 +
>  src/fontfile/fileio.c  |   1 +
>  src/fontfile/filewr.c  |   1 +
>  src/fontfile/fontdir.c |   1 +
>  src/fontfile/fontencc.c|   3 +-
>  src/fontfile/fontfile.c|  36 +++---
>  src/fontfile/fontscale.c   |   1 +
>  src/fontfile/gunzip.c  |   1 +
>  src/fontfile/register.c|   1 +
>  src/fontfile/renderers.c   |   3 +-
>  src/stubs/Makefile.am  |  19 +---
>  src/stubs/atom.c   | 234 ++
>  src/stubs/cauthgen.c   |  15 ---
>  src/stubs/csignal.c|  15 ---
>  src/stubs/delfntcid.c  |  14 ---
>  src/stubs/errorf.c |  14 ---
>  src/stubs/findoldfnt.c |  15 ---
>  src/stubs/getcres.c|  15 ---
>  src/stubs/getdefptsize.c   |  15 ---
>  src/stubs/getnewfntcid.c   |  15 ---
>  src/stubs/gettime.c|  15 ---
>  src/stubs/initfshdl.c  |  16 ---
>  src/stubs/libxfontstubs.c  | 169 
>  src/stubs/regfpefunc.c |  32 --
>  src/stubs/rmfshdl.c|  16 ---
>  src/stubs/servclient.c |  19 
>  src/stubs/setfntauth.c |  15 ---
>  src/stubs/stfntcfnt.c  |  15 ---
>  src/stubs/stubs.h  |  88 ---
>  src/stubs/stubsinit.c  |  82 --
>  src/util/Makefile.am   |   1 -
>  src/util/atom.c| 250 
> -
>  src/util/fontaccel.c   |   1 +
>  src/util/fontnames.c   |   1 +
>  src/util/fontutil.c|   1 +
>  src/util/fontxlfd.c|   1 +
>  src/util/format.c  |   1 +
>  src/util/miscutil.c|  23 +---
>  src/util/patcache.c|   1 +
>  src/util/private.c |   1 +
>  src/util/utilbitmap.c  |   1 +
>  xfont.pc.in|  13 ---
>  xfont_2.pc.in  |  13 +++
>  81 files changed, 738 insertions(+), 816 deletions(-)
>  create mode 100644 include/X11/fonts/libxfont_2.h
>  create mode 100644 include/libxfontint.h
>  create mode 100644 src/stubs/atom.c
>  delete mode 100644 src/stubs/cauthgen.c
>  delete mode 100644 src/stubs/csignal.c
>  delete mode 100644 src/stubs/delfntcid.c
>  delete mode 100644 src/stubs/errorf.c
>  delete mode 100644 src/stubs/findoldfnt.c
>  delete mode 100644 src/stubs/getcres.c
>  delete mode 100644 src/stubs/getdefptsize.c
>  delete mode 100644 src/stubs/getnewfntcid.c
>  delete mode 100644 src/stubs/gettime.c
>  delete mode 100644 

Re: [PATCH libXfont] Eliminate calls back to X server or font server functions by name (v2)

[Matt Turner]

On Wed, Sep 2, 2015 at 2:30 PM, Keith Packard  wrote:
> This eliminates the weak symbol adventures and makes all of the calls
> back to the X server or Font server go through a table of functions
> instead, clarifying the required API.
>
> As this is a rather major change to the API for the library, it now
> installs itself as libXfont2 instead of libXfont, and the package
> config file is now xfont2.pc.
>
> All of the installed headers remain the same as the original library;
> there's now a new include file, libxfont2.h, which defines the X
> server and Font server interfaces.
>
> This moves util/atom.c to stubs/atom.c and reformats that file, hence
> the diff being larger than it would otherwise be.
>
> v2: Rename to libXfont2 instead of libXfont_2 as suggested by Emil Velikov
> Fix whitespace in stubs/atom.c, which was moved from util/
>
> Signed-off-by: Keith Packard 
> ---

Does this change break the existing libXfont ABI for things other than
the xserver? Diffing the nm -DCg output, it looks like we're removing
some weak symbols, and __GetServerClient which doesn't look like it's
part of the API.

If the ABI is still compatible with libXfont-1.5.1, do we need to
change the soname?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] intel-gpu-tools: Fixes-compiler-warnings-about-wrong-function-type

[Matt Turner]

On Fri, Aug 21, 2015 at 5:20 AM, Stefan Dirsch sndir...@suse.de wrote:
 Hi

 Find another simple buildfix against current intel-gpu-tools git sources
 attached.

I think intel-gpu-tools patches are supposed to go to
intel-...@lists.freedesktop.org as inline patches.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] os: make sure the clientsWritable fd_set is initialized before use

[Matt Turner]

On Mon, Aug 3, 2015 at 8:35 AM, Keith Packard kei...@keithp.com wrote:
 Alan Coopersmith alan.coopersm...@oracle.com writes:

 For the xserver itself, you mail the patch to Keith with all the reviewed-by
 tags added to push it to the master branch (now that he's back from
 vacation).

 Nearly three weeks without a computer. Strange and weird.

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

Re: [PATCH 1/4] modesetting: Implement 32-24 bpp conversion in shadow update

[Matt Turner]

On Wed, Jul 22, 2015 at 9:14 AM, Adam Jackson a...@redhat.com wrote:
 From: Dave Airlie airl...@redhat.com

 24bpp front buffers tend to be the least well tested path for client
 rendering.  On the qemu cirrus emulation, and on some Matrox G200 server
 chips, the hardware can't do 32bpp at all.  It's better to just allocate
 a 32bpp shadow and downconvert in the upload hook than expose a funky
 pixmap format to clients.

 [ajax: Ported from RHEL and separate modesetting driver, lifted kbpp
 into the drmmode struct, cleaned up commit message, fixed 16bpp]

 Reviewed-by: Adam Jackson a...@redhat.com
 Signed-off-by: Dave Airlied airl...@redhat.com
 ---
  hw/xfree86/drivers/modesetting/Makefile.am   |   2 +
  hw/xfree86/drivers/modesetting/driver.c  |  41 ---
  hw/xfree86/drivers/modesetting/drmmode_display.c |  24 ++--
  hw/xfree86/drivers/modesetting/drmmode_display.h |   2 +
  hw/xfree86/drivers/modesetting/sh3224.c  | 140 
 +++
  hw/xfree86/drivers/modesetting/sh3224.h  |   7 ++
  6 files changed, 193 insertions(+), 23 deletions(-)
  create mode 100644 hw/xfree86/drivers/modesetting/sh3224.c
  create mode 100644 hw/xfree86/drivers/modesetting/sh3224.h

 diff --git a/hw/xfree86/drivers/modesetting/Makefile.am 
 b/hw/xfree86/drivers/modesetting/Makefile.am
 index 82c4f2f..ca7e05a 100644
 --- a/hw/xfree86/drivers/modesetting/Makefile.am
 +++ b/hw/xfree86/drivers/modesetting/Makefile.am
 @@ -51,6 +51,8 @@ modesetting_drv_la_SOURCES = \
  dumb_bo.c \
  dumb_bo.h \
  present.c \
 +sh3224.c \
 +sh3224.h \
  vblank.c \
  $(NULL)

 diff --git a/hw/xfree86/drivers/modesetting/driver.c 
 b/hw/xfree86/drivers/modesetting/driver.c
 index 324b8bd..68a865f 100644
 --- a/hw/xfree86/drivers/modesetting/driver.c
 +++ b/hw/xfree86/drivers/modesetting/driver.c
 @@ -60,6 +60,7 @@
  #endif

  #include driver.h
 +#include sh3224.h

  static void AdjustFrame(ScrnInfoPtr pScrn, int x, int y);
  static Bool CloseScreen(ScreenPtr pScreen);
 @@ -770,10 +771,16 @@ PreInit(ScrnInfoPtr pScrn, int flags)
  }
  #endif
  drmmode_get_default_bpp(pScrn, ms-drmmode, defaultdepth, defaultbpp);
 -if (defaultdepth == 24  defaultbpp == 24)
 -bppflags = SupportConvert32to24 | Support24bppFb;
 -else
 -bppflags = PreferConvert24to32 | SupportConvert24to32 | 
 Support32bppFb;
 +if (defaultdepth == 24  defaultbpp == 24) {
 +   ms-drmmode.force_24_32 = TRUE;
 +   ms-drmmode.kbpp = 24;
 +   xf86DrvMsg(pScrn-scrnIndex, X_INFO,
 +  Using 24bpp hw front buffer with 32bpp shadow\n);
 +   defaultbpp = 32;
 +} else {
 +   ms-drmmode.kbpp = defaultbpp;
 +}
 +bppflags = PreferConvert24to32 | SupportConvert24to32 | Support32bppFb;

  if (!xf86SetDepthBpp
  (pScrn, defaultdepth, defaultdepth, defaultbpp, bppflags))
 @@ -827,18 +834,24 @@ PreInit(ScrnInfoPtr pScrn, int flags)
  } else {
  Bool prefer_shadow = TRUE;

 -ret = drmGetCap(ms-fd, DRM_CAP_DUMB_PREFER_SHADOW, value);
 -if (!ret) {
 -prefer_shadow = !!value;
 -}
 +   if (ms-drmmode.force_24_32) {
 +   prefer_shadow = TRUE;
 +   ms-drmmode.shadow_enable = TRUE;
 +   } else {
 +   ret = drmGetCap(ms-fd, DRM_CAP_DUMB_PREFER_SHADOW, value);
 +   if (!ret) {
 +   prefer_shadow = !!value;
 +   }

 -ms-drmmode.shadow_enable = xf86ReturnOptValBool(ms-Options,
 - OPTION_SHADOW_FB,
 - prefer_shadow);
 +   ms-drmmode.shadow_enable = xf86ReturnOptValBool(ms-Options,
 +OPTION_SHADOW_FB,
 +prefer_shadow);
 +   }

  xf86DrvMsg(pScrn-scrnIndex, X_INFO,
 ShadowFB: preferred %s, enabled %s\n,
 prefer_shadow ? YES : NO,
 +  ms-drmmode.force_24_32 ? FORCE :
 ms-drmmode.shadow_enable ? YES : NO);

  ms-drmmode.pageflip = FALSE;
 @@ -894,7 +907,7 @@ msShadowWindow(ScreenPtr screen, CARD32 row, CARD32 
 offset, int mode,
  modesettingPtr ms = modesettingPTR(pScrn);
  int stride;

 -stride = (pScrn-displayWidth * pScrn-bitsPerPixel) / 8;
 +stride = (pScrn-displayWidth * ms-drmmode.kbpp) / 8;
  *size = stride;

  return ((uint8_t *) ms-drmmode.front_bo.dumb-ptr + row * stride + 
 offset);
 @@ -915,6 +928,7 @@ CreateScreenResources(ScreenPtr pScreen)
  Bool ret;
  void *pixels = NULL;
  int err;
 +Bool use_ms_shadow = ms-drmmode.force_24_32  pScrn-bitsPerPixel == 
 32;

  pScreen-CreateScreenResources = ms-createScreenResources;
  ret = pScreen-CreateScreenResources(pScreen);
 @@ -946,7 +960,8 @@ CreateScreenResources(ScreenPtr pScreen)

Re: [PATCH 5/7] glamor: compute GLSL version from GL_SHADING_LANGUAGE_VERSION

[Matt Turner]

On Tue, May 12, 2015 at 7:56 AM, Keith Packard kei...@keithp.com wrote:
 Kenneth Graunke kenn...@whitecape.org writes:

 If you care about making that work, I recommend swiping Piglit's
 piglit_get_glsl_version() function, available here:
 http://cgit.freedesktop.org/piglit/tree/tests/util/piglit-shader.c#n28

 Thanks. What kind of copyright holder is 'The Piglit project'?

Not a real one...

Looks like the code blames to Chad in commit 112eaa05, so that would
be copyright Intel 2011.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [5/5] Xephyr: Fix broken image when endianess of client machine and host-Xserver differ

[Matt Turner]

On Tue, May 5, 2015 at 11:07 AM, Ian Scott ian.sc...@arteris.com wrote:
 On 03/31/2015 12:14 AM, Egbert Eich wrote:

 The image is created in the native byte order of the machine Xephyr is
 rendered on however drawn in the image byte order of the Xephyr server.
 Correct byte order in the xcb_image_t structure and convert to native
 before updating the window.
 If depths of Xephyr and host server differ this is already taken care of
 by the depth conversion routine.
 It is a terrible wase to always convert and transmit the entire image
 no matter of the size of the damaged area. One should probably use
 sub-images here. For now we leave this as an exercise.


 I have a patch that implements this with subimages. Should I submit a patch
 based on git master HEAD or based on this patch?

I expect Egbert's patch will be committed, so probably best to do it
on top of that.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] backtrace.c: Fix word cast to a pointer

[Matt Turner]

On Wed, Apr 1, 2015 at 2:13 AM, Vicente Olivert Riera
vincent.ri...@imgtec.com wrote:
 Hello,

 On 01/08/2015 10:36 PM, Keith Packard wrote:
 Vicente Olivert Riera vincent.ri...@imgtec.com writes:

 Making the cast to a pointer-sized integer, and then to a pointer fixes
 the problem.

 -if (dladdr((void *)(pip.start_ip + off), dlinfo)  
 dlinfo.dli_fname 
 +if (dladdr((void *)(long)(pip.start_ip + off), dlinfo)  
 dlinfo.dli_fname 

 I'd suggest using uintptr_t instead of long if you want a pointer-sized
 integer.


 out of curiosity. Why is taking so long for this patch to be applied
 upstream?

I don't see that you ever sent an updated patch. Though I do have a
vague memory of making the same comment as Keith, I can't find the
thread I would have made it in.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 06/17] Add no-fail equivalents of allocarray reallocarray

[Matt Turner]

On Tue, Mar 31, 2015 at 5:50 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  include/os.h |9 +
  os/utils.c   |   10 ++
  2 files changed, 19 insertions(+)

 diff --git a/include/os.h b/include/os.h
 index 2633741..bc624a2 100644
 --- a/include/os.h
 +++ b/include/os.h
 @@ -76,6 +76,8 @@ typedef struct _NewClientRec *NewClientPtr;
  #define xnfstrdup(s) XNFstrdup(s)

  #define xallocarray(num, size) reallocarray(NULL, (num), (size))
 +#define xnfallocarray(num, size) XNFreallocarray(NULL, (num), (size))
 +#define xnfreallocarray(ptr, num, size) XNFreallocarray((ptr), (num), (size))
  #endif

  #include stdio.h
 @@ -241,6 +243,13 @@ extern _X_EXPORT void *
  XNFrealloc(void * /*ptr */ , unsigned long /*amount */ );

  /*
 + * This function reallocarrays(3)s passed buffer, terminating the server if

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

Re: [PATCH 08/17] Convert dix/* to new *allocarray functions

[Matt Turner]

On Tue, Mar 31, 2015 at 5:50 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  dix/atom.c   |4 +--
  dix/colormap.c   |   71 
 +++---
  dix/devices.c|4 +--
  dix/dispatch.c   |4 +--
  dix/dixfonts.c   |   18 ++
  dix/enterleave.c |2 +-
  dix/events.c |4 +--
  dix/extension.c  |6 ++---
  dix/grabs.c  |8 +++---
  dix/property.c   |   10 
  dix/region.c |2 +-
  dix/resource.c   |6 ++---
  dix/touch.c  |8 +++---
  13 files changed, 71 insertions(+), 76 deletions(-)

 diff --git a/dix/atom.c b/dix/atom.c
 index 22cd0dc..4596545 100644
 --- a/dix/atom.c
 +++ b/dix/atom.c
 @@ -119,7 +119,7 @@ MakeAtom(const char *string, unsigned len, Bool makeit)
  if ((lastAtom + 1) = tableLength) {
  NodePtr *table;

 -table = realloc(nodeTable, tableLength * (2 * sizeof(NodePtr)));
 +table = reallocarray(nodeTable, tableLength, (2 * 
 sizeof(NodePtr)));

Remove extra parentheses.

  if (!table) {
  if (nd-string != string) {
  /* nd-string has been strdup'ed */
 @@ -200,7 +200,7 @@ InitAtoms(void)
  {
  FreeAllAtoms();
  tableLength = InitialTableSize;
 -nodeTable = malloc(InitialTableSize * sizeof(NodePtr));
 +nodeTable = xallocarray(InitialTableSize, sizeof(NodePtr));
  if (!nodeTable)
  AtomError();
  nodeTable[None] = NULL;
 diff --git a/dix/colormap.c b/dix/colormap.c
 index 4d408d5..36df08f 100644
 --- a/dix/colormap.c
 +++ b/dix/colormap.c
 @@ -296,7 +296,7 @@ CreateColormap(Colormap mid, ScreenPtr pScreen, VisualPtr 
 pVisual,
  for (pent = pmap-red[size - 1]; pent = pmap-red; pent--)
  pent-refcnt = AllocPrivate;
  pmap-freeRed = 0;
 -ppix = malloc(size * sizeof(Pixel));
 +ppix = xallocarray(size, sizeof(Pixel));
  if (!ppix) {
  free(pmap);
  return BadAlloc;
 @@ -337,7 +337,7 @@ CreateColormap(Colormap mid, ScreenPtr pScreen, VisualPtr 
 pVisual,
  for (pent = pmap-green[size - 1]; pent = pmap-green; pent--)
  pent-refcnt = AllocPrivate;
  pmap-freeGreen = 0;
 -ppix = malloc(size * sizeof(Pixel));
 +ppix = xallocarray(size, sizeof(Pixel));
  if (!ppix) {
  free(pmap-clientPixelsRed[client]);
  free(pmap);
 @@ -352,7 +352,7 @@ CreateColormap(Colormap mid, ScreenPtr pScreen, VisualPtr 
 pVisual,
  for (pent = pmap-blue[size - 1]; pent = pmap-blue; pent--)
  pent-refcnt = AllocPrivate;
  pmap-freeBlue = 0;
 -ppix = malloc(size * sizeof(Pixel));
 +ppix = xallocarray(size, sizeof(Pixel));
  if (!ppix) {
  free(pmap-clientPixelsGreen[client]);
  free(pmap-clientPixelsRed[client]);
 @@ -702,7 +702,7 @@ UpdateColors(ColormapPtr pmap)

  pVisual = pmap-pVisual;
  size = pVisual-ColormapEntries;
 -defs = malloc(size * sizeof(xColorItem));
 +defs = xallocarray(size, sizeof(xColorItem));
  if (!defs)
  return;
  n = 0;
 @@ -792,8 +792,8 @@ AllocColor(ColormapPtr pmap,
  *pgreen = pmap-red[pixR].co.local.green;
  *pblue = pmap-red[pixR].co.local.blue;
  npix = pmap-numPixelsRed[client];
 -ppix = (Pixel *) realloc(pmap-clientPixelsRed[client],
 - (npix + 1) * sizeof(Pixel));
 +ppix = reallocarray(pmap-clientPixelsRed[client],
 +(npix + 1), sizeof(Pixel));

And here.

  if (!ppix)
  return BadAlloc;
  ppix[npix] = pixR;
 @@ -814,22 +814,22 @@ AllocColor(ColormapPtr pmap,
  *pgreen = pmap-green[pixG].co.local.green;
  *pblue = pmap-blue[pixB].co.local.blue;
  npix = pmap-numPixelsRed[client];
 -ppix = (Pixel *) realloc(pmap-clientPixelsRed[client],
 - (npix + 1) * sizeof(Pixel));
 +ppix = reallocarray(pmap-clientPixelsRed[client],
 +(npix + 1), sizeof(Pixel));

And here.

  if (!ppix)
  return BadAlloc;
  ppix[npix] = pixR;
  pmap-clientPixelsRed[client] = ppix;
  npix = pmap-numPixelsGreen[client];
 -ppix = (Pixel *) realloc(pmap-clientPixelsGreen[client],
 - (npix + 1) * sizeof(Pixel));
 +ppix = reallocarray(pmap-clientPixelsGreen[client],
 +(npix + 1), sizeof(Pixel));

And here. (and other places below. I don't think you need me to point them out)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 00/17] Improved overflow checking for memory allocations

[Matt Turner]

On Tue, Mar 31, 2015 at 5:50 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 This series of patches borrows the reallocarray() interface from OpenBSD,
 improves our xcalloc interfaces, and generally cleans up our array memory
 allocation code to check calculations for memory allocations do not have
 integer overflows in several more places than we previously checked.

 Most of these probably couldn't overflow before, but now we can be sure
 without having to do tedious manual analysis of each one, and without
 giving the compiler a reason to assume that we must not have overflowed,
 and thus optimize out any overflow checks that may have been in the wrong
 order previously.

Nice. All but 04/17 are

Reviewed-by: Matt Turner matts...@gmail.com

And 04/17 is

Acked-by: Matt Turner matts...@gmail.com

I suspect you did most of this with Coccinelle, but I definitely
noticed an attention to detail that shows that some of this must have
been manual. E.g., transforming malloc(3 * size * sizeof(CARD16)) into

| xallocarray(length, 3 * sizeof(CARD16))

instead of

| xallocarray(3 * length, sizeof(CARD16))

so that the 3 * sizeof(CARD16) can be evaluated at compile time. Nice
of you to get rid of some useless casts as well.

It's minorly unfortunate that a lot of these multiplies (that are by
powers of two) can no longer be turned into shifts, but I guess that's
the price of some additional safety.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 07/17] Convert os/* to new *allocarray functions

[Matt Turner]

On Tue, Mar 31, 2015 at 5:50 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  os/connection.c |   13 +++--
  os/utils.c  |2 +-
  2 files changed, 8 insertions(+), 7 deletions(-)

 diff --git a/os/connection.c b/os/connection.c
 index 7ff44e1..5dec02f 100644
 --- a/os/connection.c
 +++ b/os/connection.c
 @@ -309,7 +309,7 @@ InitConnectionLimits(void)

  #if !defined(WIN32)
  if (!ConnectionTranslation)
 -ConnectionTranslation = (int *) xnfalloc(sizeof(int) * (lastfdesc + 
 1));
 +ConnectionTranslation = xnfallocarray(lastfdesc + 1, sizeof(int));
  #else
  InitConnectionTranslation();
  #endif
 @@ -429,7 +429,9 @@ CreateWellKnownSockets(void)
  display = dynamic_display;
  }

 -ListenTransFds = malloc(ListenTransCount * sizeof (int));
 +ListenTransFds = xallocarray(ListenTransCount, sizeof (int));
 +if (ListenTransFds == NULL)
 +FatalError (Failed to create listening socket array);

  for (i = 0; i  ListenTransCount; i++) {
  int fd = _XSERVTransGetConnectionNumber(ListenTransConns[i]);
 @@ -1291,11 +1293,10 @@ ListenOnOpenFD(int fd, int noxauth)

  /* Allocate space to store it */
  ListenTransFds =
 -(int *) realloc(ListenTransFds, (ListenTransCount + 1) * 
 sizeof(int));
 +xnfreallocarray(ListenTransFds, (ListenTransCount + 1), sizeof(int));

Probably remove the now useless parentheses here.

  ListenTransConns =
 -(XtransConnInfo *) realloc(ListenTransConns,
 -   (ListenTransCount +
 -1) * sizeof(XtransConnInfo));
 +xnfreallocarray(ListenTransConns, (ListenTransCount + 1),

And here.

 +sizeof(XtransConnInfo));

  /* Store it */
  ListenTransConns[ListenTransCount] = ciptr;
 diff --git a/os/utils.c b/os/utils.c
 index 23f4117..cd1cf42 100644
 --- a/os/utils.c
 +++ b/os/utils.c
 @@ -2001,7 +2001,7 @@ xstrtokenize(const char *str, const char *separators)
  if (!tmp)
  goto error;
  for (tok = strtok(tmp, separators); tok; tok = strtok(NULL, separators)) 
 {
 -nlist = realloc(list, (num + 2) * sizeof(*list));
 +nlist = reallocarray(list, (num + 2), sizeof(*list));

And here.

  if (!nlist)
  goto error;
  list = nlist;
 --
 1.7.9.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 12/17] Convert mi miext to new *allocarray functions

[Matt Turner]

On Tue, Mar 31, 2015 at 5:50 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
 ---
  mi/miarc.c  |   25 +++
  mi/mibitblt.c   |   16 +++
  mi/micmap.c |8 
  mi/micopy.c |4 ++--
  mi/miexpose.c   |2 +-
  mi/mifillrct.c  |4 ++--
  mi/miglblt.c|2 +-
  mi/miinitext.c  |4 ++--
  mi/mipoly.c |4 ++--
  mi/mipolypnt.c  |2 +-
  mi/mipolyrect.c |2 +-
  mi/miwideline.c |   42 
 ++-
  mi/miwindow.c   |6 +++---
  mi/mizerarc.c   |4 ++--
  mi/mizerline.c  |4 ++--
  miext/damage/damage.c   |2 +-
  miext/rootless/rootlessWindow.c |4 ++--
  miext/shadow/shalloc.c  |2 +-
  18 files changed, 66 insertions(+), 71 deletions(-)

 diff --git a/mi/miarc.c b/mi/miarc.c
 index e8bc87e..6a12534 100644
 --- a/mi/miarc.c
 +++ b/mi/miarc.c
 @@ -1187,9 +1187,9 @@ miFillSppPoly(DrawablePtr dst, GCPtr pgc, int count,
 /* number of points */
  y = ymax - ymin + 1;
  if ((count  3) || (y = 0))
  return;
 -ptsOut = FirstPoint = malloc(sizeof(DDXPointRec) * y);
 -width = FirstWidth = malloc(sizeof(int) * y);
 -Marked = malloc(sizeof(int) * count);
 +ptsOut = FirstPoint = xallocarray(y, sizeof(DDXPointRec));
 +width = FirstWidth = xallocarray(y, sizeof(int));
 +Marked = xallocarray(count, sizeof(int));

  if (!ptsOut || !width || !Marked) {
  free(Marked);
 @@ -1679,8 +1679,7 @@ miGetArcPts(SppArcPtr parc, /* points to an arc */
  count++;

  cdt = 2 * miDcos(dt);
 -if (!(poly = (SppPointPtr) realloc((void *) *ppPts,
 -   (cpt + count) * sizeof(SppPointRec
 +if (!(poly = reallocarray(*ppPts, cpt + count, sizeof(SppPointRec
  return 0;
  *ppPts = poly;

 @@ -1737,7 +1736,7 @@ addCap(miArcCapPtr * capsp, int *ncapsp, int *sizep, 
 int end, int arcIndex)

  if (*ncapsp == *sizep) {
  newsize = *sizep + ADD_REALLOC_STEP;
 -cap = (miArcCapPtr) realloc(*capsp, newsize * sizeof(**capsp));
 +cap = reallocarray(*capsp, newsize, sizeof(**capsp));
  if (!cap)
  return;
  *sizep = newsize;
 @@ -1760,7 +1759,7 @@ addJoin(miArcJoinPtr * joinsp,

  if (*njoinsp == *sizep) {
  newsize = *sizep + ADD_REALLOC_STEP;
 -join = (miArcJoinPtr) realloc(*joinsp, newsize * sizeof(**joinsp));
 +join = reallocarray(*joinsp, newsize, sizeof(**joinsp));
  if (!join)
  return;
  *sizep = newsize;
 @@ -1784,7 +1783,7 @@ addArc(miArcDataPtr * arcsp, int *narcsp, int *sizep, 
 xArc * xarc)

  if (*narcsp == *sizep) {
  newsize = *sizep + ADD_REALLOC_STEP;
 -arc = (miArcDataPtr) realloc(*arcsp, newsize * sizeof(**arcsp));
 +arc = reallocarray(*arcsp, newsize, sizeof(**arcsp));
  if (!arc)
  return NULL;
  *sizep = newsize;
 @@ -1890,10 +1889,10 @@ miComputeArcs(xArc * parcs, int narcs, GCPtr pGC)
  isDoubleDash = (pGC-lineStyle == LineDoubleDash);
  dashOffset = pGC-dashOffset;

 -data = malloc(narcs * sizeof(struct arcData));
 +data = xallocarray(narcs, sizeof(struct arcData));
  if (!data)
  return NULL;
 -arcs = malloc(sizeof(*arcs) * (isDoubleDash ? 2 : 1));
 +arcs = xallocarray((isDoubleDash ? 2 : 1), sizeof(*arcs));

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

Re: [PATCH] Byte-swapping and size-checking generator all-in-one

[Matt Turner]

On Mon, Mar 23, 2015 at 11:16 PM, Asal Mirzaieva asalle@gmail.com wrote:
 On 17.03.15 09:25, Peter Hutterer wrote:
 whoah, that is a lot of tabs...

 I assumed tab = 4 spaces, as it is defined in
 http://www.x.org/wiki/CodingStyle/. As python strictly requires tabs and not
 space-indents, I thought it would be the nicer way to organize code. But I
 will switch to tab = 8 spaces and fix all the tabs issues.

That's not true. See https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Spaces are preferred in Python.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] config: Support multiple 'Files' sections

[Matt Turner]

On Thu, Feb 26, 2015 at 1:55 PM, Michał Górny mgo...@gentoo.org wrote:
 Support reading multiple 'Files' sections in configuration,
 concatenating the resulting paths. This makes it possible to add
 ModulePaths and FontPaths within xorg.conf.d/ files without interfering
 with user-provided xorg.conf. Gentoo needs this to support using
 replacement xorg modules provided by proprietary video drivers.

 Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88003
 Signed-off-by: Michał Górny mgo...@gentoo.org
 ---
 [not subscribed, please CC me on replies]

  hw/xfree86/parser/Files.c   | 8 ++--
  hw/xfree86/parser/configProcs.h | 2 +-
  hw/xfree86/parser/read.c| 2 +-
  3 files changed, 8 insertions(+), 4 deletions(-)

 diff --git a/hw/xfree86/parser/Files.c b/hw/xfree86/parser/Files.c
 index 849bf92..5cc3ec7 100644
 --- a/hw/xfree86/parser/Files.c
 +++ b/hw/xfree86/parser/Files.c
 @@ -76,14 +76,18 @@ static xf86ConfigSymTabRec FilesTab[] = {
  #define CLEANUP xf86freeFiles

  XF86ConfFilesPtr
 -xf86parseFilesSection(void)
 +xf86parseFilesSection(XF86ConfFilesPtr ptr)
  {
  int i, j;
  int k, l;
  char *str;
  int token;

 -parsePrologue(XF86ConfFilesPtr, XF86ConfFilesRec)
 +if (!ptr) {
 +if( (ptr=calloc(1,sizeof(XF86ConfFilesRec))) == NULL ) {

Style issues:
  - space between if and (
  - no spaces between parentheses and the conditional expression
  - spaces around =
  - space after comma

On IRC, Keith says the patch has a memory leak, but that there are
some existing ones in this code already. I'm not sure if he wants you
to fix the one you're adding or not worry about it.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] config: Support multiple 'Files' sections

[Matt Turner]

On Mon, Mar 9, 2015 at 12:10 PM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2015-03-09, o godz. 12:04:31
 Matt Turner matts...@gmail.com napisał(a):

 On Thu, Feb 26, 2015 at 1:55 PM, Michał Górny mgo...@gentoo.org wrote:
  Support reading multiple 'Files' sections in configuration,
  concatenating the resulting paths. This makes it possible to add
  ModulePaths and FontPaths within xorg.conf.d/ files without interfering
  with user-provided xorg.conf. Gentoo needs this to support using
  replacement xorg modules provided by proprietary video drivers.
 
  Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=88003
  Signed-off-by: Michał Górny mgo...@gentoo.org
  ---
  [not subscribed, please CC me on replies]
 
   hw/xfree86/parser/Files.c   | 8 ++--
   hw/xfree86/parser/configProcs.h | 2 +-
   hw/xfree86/parser/read.c| 2 +-
   3 files changed, 8 insertions(+), 4 deletions(-)
 
  diff --git a/hw/xfree86/parser/Files.c b/hw/xfree86/parser/Files.c
  index 849bf92..5cc3ec7 100644
  --- a/hw/xfree86/parser/Files.c
  +++ b/hw/xfree86/parser/Files.c
  @@ -76,14 +76,18 @@ static xf86ConfigSymTabRec FilesTab[] = {
   #define CLEANUP xf86freeFiles
 
   XF86ConfFilesPtr
  -xf86parseFilesSection(void)
  +xf86parseFilesSection(XF86ConfFilesPtr ptr)
   {
   int i, j;
   int k, l;
   char *str;
   int token;
 
  -parsePrologue(XF86ConfFilesPtr, XF86ConfFilesRec)
  +if (!ptr) {
  +if( (ptr=calloc(1,sizeof(XF86ConfFilesRec))) == NULL ) {

 Style issues:
   - space between if and (
   - no spaces between parentheses and the conditional expression
   - spaces around =
   - space after comma

 That ugly part is copied from the macro used in other functions. Are
 you sure you want it changed here and left ugly in the macro?

I expect so -- when the xserver was reindented a few years ago I bet
macros weren't handled.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] glamor: Perform texture2D() separately from swizzle.

[Matt Turner]

The texture2D() happens in each branch, so we may as well do it as early
as possible and hide some of its latency in the branching instructions.
Moving it outside the (uniform) control flow reduces the number of
instructions in the fs_source shader from 64 to 46 and in the
set_alpha_source shader from 69 to 47 on Haswell.
---
Untested. Given a short primer on benchmarking glamor I'd be happy
to run some benchmarks.

 glamor/glamor_core.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 737b274..a26f8f9 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -173,46 +173,48 @@ glamor_init_finish_access_shaders(ScreenPtr screen)
 const char *fs_source =
 void main()\n
 {\n
+   vec4 color = texture2D(sampler, source_texture);\n
if (revert == REVERT_NONE) \n
 { \n
  if ((swap_rb != SWAP_NONE_DOWNLOADING)  (swap_rb != 
SWAP_NONE_UPLOADING))   \n
-  gl_FragColor = texture2D(sampler, 
source_texture).bgra;\n
+  gl_FragColor = color.bgra;\n
  else \n
-  gl_FragColor = texture2D(sampler, 
source_texture).rgba;\n
+  gl_FragColor = color.rgba;\n
 } \n
else \n
 { \n
  if (swap_rb == SWAP_DOWNLOADING)   \n
-  gl_FragColor = texture2D(sampler, 
source_texture).argb;\n
+  gl_FragColor = color.argb;\n
  else if (swap_rb == SWAP_NONE_DOWNLOADING)\n
-  gl_FragColor = texture2D(sampler, 
source_texture).abgr;\n
+  gl_FragColor = color.abgr;\n
  else if (swap_rb == SWAP_UPLOADING)\n
-  gl_FragColor = texture2D(sampler, 
source_texture).gbar;\n
+  gl_FragColor = color.gbar;\n
  else if (swap_rb == SWAP_NONE_UPLOADING)\n
-  gl_FragColor = texture2D(sampler, 
source_texture).abgr;\n
+  gl_FragColor = color.abgr;\n
 } \n
 }\n;
 
 const char *set_alpha_source =
 void main()\n
 {\n
+   vec4 color = texture2D(sampler, source_texture);\n
if (revert == REVERT_NONE) \n
 { \n
  if ((swap_rb != SWAP_NONE_DOWNLOADING)  (swap_rb != 
SWAP_NONE_UPLOADING))   \n
-  gl_FragColor = vec4(texture2D(sampler, 
source_texture).bgr, 1);\n
+  gl_FragColor = vec4(color.bgr, 1);\n
  else \n
-  gl_FragColor = vec4(texture2D(sampler, 
source_texture).rgb, 1);\n
+  gl_FragColor = vec4(color.rgb, 1);\n
 } \n
else \n
 { \n
  if (swap_rb == SWAP_DOWNLOADING)   \n
-  gl_FragColor = vec4(1, texture2D(sampler, 
source_texture).rgb);\n
+  gl_FragColor = vec4(1, color.rgb);\n
  else if (swap_rb == SWAP_NONE_DOWNLOADING)\n
-  gl_FragColor = vec4(1, texture2D(sampler, 
source_texture).bgr);\n
+  gl_FragColor = vec4(1, color.bgr);\n
  else if (swap_rb == SWAP_UPLOADING)\n
-  gl_FragColor = vec4(texture2D(sampler, 
source_texture).gba, 1);\n
+  gl_FragColor = vec4(color.gba, 1);\n
  else if (swap_rb == SWAP_NONE_UPLOADING)\n
-  gl_FragColor = vec4(texture2D(sampler, 
source_texture).abg, 1);\n
+  gl_FragColor = vec4(color.abg, 1);\n
 } \n
 }\n;
 GLint fs_prog, vs_prog, avs_prog, set_alpha_prog;
-- 
2.0.5

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

Re: close-on-exec

[Matt Turner]

On Fri, Feb 27, 2015 at 5:04 PM, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
 On 02/26/15 01:34 AM, Thomas Klausner wrote:

 On Wed, Feb 25, 2015 at 02:27:30PM -0800, Alan Coopersmith wrote:

 Solaris has the ancient support for setting the FD_CLOEXEC flag via
 fcntl() in all versions, and the more recent support for the O_CLOEXEC
 flag to open() in Solaris 11 and later, but does not yet support the
 e flag to fopen().  (I've filed an enhancement request to add it to
 our libc in the future, but that doesn't help today.)

 I believe the most portable way to do this is:

 if (!(addfp = fopen (addAuthFile, w)))
 goto bad;
 else
 fcntl(fileno(addfp), F_SETFD, FD_CLOEXEC);

 That would be subject to race conditions in multi-threaded processes, as
 described in https://udrepper.livejournal.com/20407.html, so not safe in
 libraries or programs which deliberately start multiple threads, but
 since
 xsm is not one of those, it should be mostly safe. (Not completely,
 because
 we can't be sure nothing we called in a library didn't start a thread
 behind
 the scenes to handle one of our requests, but without an e flag
 everywhere,
 I'm not sure what more we can do.  I have no idea how to write a
 configure
 check to test for fopen(..., e) support either.)


 Ok, so let's use fcntl for now, new patch attached.


 Is there some reason all the fcntl returns are cast to (void)?

 I know we do that in native Solaris code for lint's checks, but I wasn't
 aware of other tools requiring that and know a bunch of return casts to
 void have been removed from the X code base over the years.

I've certainly seen gcc complain about not checking return values, and
usually casting to void tells it to be quiet.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xf86-video-mga] Fix pointer cast warning.

[Matt Turner]

On Mon, Feb 23, 2015 at 2:39 AM, Thomas Klausner w...@netbsd.org wrote:
 cast to pointer from integer of different size [-Werror=int-to-pointer-cast]

 Signed-off-by: Thomas Klausner w...@netbsd.org
 ---
  src/mga_exa.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/mga_exa.c b/src/mga_exa.c
 index 69ffa16..5024f54 100644
 --- a/src/mga_exa.c
 +++ b/src/mga_exa.c
 @@ -729,7 +729,7 @@ mgaDownloadFromScreen(PixmapPtr pSrc, int x, int y, int 
 w, int h,
  {
  PMGA(pSrc);

 -char *src = (char *) exaGetPixmapFirstPixel(pSrc);
 +char *src = (char *)(unsigned long) exaGetPixmapFirstPixel(pSrc);

Use u/intptr_t. From there, I don't remember if the explicit char*
cast is necessary.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xf86-video-mga 2/2] Use correct type in function call.

[Matt Turner]

On Mon, Feb 23, 2015 at 4:28 AM, Thomas Klausner w...@netbsd.org wrote:
 Fixes
 passing argument 2 of 'pci_device_cfg_read_u32' from incompatible pointer type
 pciaccess.h:153:5: note: expected '__uint32_t *' but argument is of type 
 'CARD32 *'

 Signed-off-by: Thomas Klausner w...@netbsd.org
 ---
  src/mga_dac3026.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

 diff --git a/src/mga_dac3026.c b/src/mga_dac3026.c
 index 97c2c7a..e825702 100644
 --- a/src/mga_dac3026.c
 +++ b/src/mga_dac3026.c
 @@ -852,8 +852,12 @@ MGA3026Save(ScrnInfoPtr pScrn, vgaRegPtr vgaReg, 
 MGARegPtr mgaReg,
 mgaReg-DacRegs[i]   = inTi3026(MGADACregs[i]);

  #ifdef XSERVER_LIBPCIACCESS
 -   pci_device_cfg_read_u32(pMga-PciInfo,  mgaReg-Option,
 +{
 +   uint32_t Option;
 +   pci_device_cfg_read_u32(pMga-PciInfo,  Option,
 PCI_OPTION_REG);
 +mgaReg-Option = Option;

I don't understand why the previous code generated that warning (isn't
__uint32_t* implicitly castable to CARD32*?) but even so, why isn't a
cast the appropriate solution?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [w...@netbsd.org: [PATCH:xf86-video-glint] Fix DDC2 on PGX32/Raptor 8P]

[Matt Turner]

On Thu, Feb 19, 2015 at 3:07 PM, Thomas Klausner w...@netbsd.org wrote:
 On Thu, Feb 19, 2015 at 10:08:09AM -0800, Matt Turner wrote:
 No, that patch looks like a hack. It's attempting to do the same as
 Alan's patch, but Alan's patch, minus the incorrect comment, is better
 believable. That is, of course, assuming someone has tested it and
 confirmed that it fixes the problem.

 Well, I've tried to get Michael to test Alan's patch, but he seems to
 have mislaid his glint hardware. :(
 Not sure what the best way to proceed is in this case.
  Thomas

I've got a Blade 2500 and PGX32... I think. It'd take some work to get
it set up in a fashion that would let me test this, and I'm not sure
it's worth the effort.

If the only person who had this bug can't find his hardware, I'm not
sure we should put a lot of effort into it.

If he does test the patch, let me know. I'll be sure to let you know
if I get bored enough to do it myself. :)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [w...@netbsd.org: [PATCH:xf86-video-glint] Fix DDC2 on PGX32/Raptor 8P]

[Matt Turner]

On Thu, Feb 19, 2015 at 6:28 AM, Thomas Klausner w...@netbsd.org wrote:
 On Wed, Feb 18, 2015 at 10:49:35PM -0800, Matt Turner wrote:
 On Fri, Jul 12, 2013 at 3:30 AM, Thomas Klausner w...@netbsd.org wrote:
  Hi Alan!
 
  Thanks for the patch. I can't test myself, but have forwarded your
  patch to Michael Lorenz, who came up with the original patch. I hope
  he'll find time to test it soon.
   Thomas
 
  On Thu, Jul 11, 2013 at 11:55:00AM +0100, Alan wrote:
  I took a quick look and it seems that this bit doesn't exist on PM3,
  only PM2.
 
  Can you test this alternative patch ?
 
  Thanks,
 
  Alan.

 I just noticed this when going through some old email and checked my
 Permedia docs.

 My Permedia3 and 4 docs says bit 9 UseMonitorID exists, same
 behavior as Permedia 2.

 Thanks for checking up on this. Does this mean we can commit the patch
 Michael suggested (attached again)?
  Thomas

No, that patch looks like a hack. It's attempting to do the same as
Alan's patch, but Alan's patch, minus the incorrect comment, is better
believable. That is, of course, assuming someone has tested it and
confirmed that it fixes the problem.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [w...@netbsd.org: [PATCH:xf86-video-glint] Fix DDC2 on PGX32/Raptor 8P]

[Matt Turner]

On Fri, Jul 12, 2013 at 3:30 AM, Thomas Klausner w...@netbsd.org wrote:
 Hi Alan!

 Thanks for the patch. I can't test myself, but have forwarded your
 patch to Michael Lorenz, who came up with the original patch. I hope
 he'll find time to test it soon.
  Thomas

 On Thu, Jul 11, 2013 at 11:55:00AM +0100, Alan wrote:
 I took a quick look and it seems that this bit doesn't exist on PM3,
 only PM2.

 Can you test this alternative patch ?

 Thanks,

 Alan.

I just noticed this when going through some old email and checked my
Permedia docs.

My Permedia3 and 4 docs says bit 9 UseMonitorID exists, same
behavior as Permedia 2.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] glamor: * 1/size is faster than / size in VS

[Matt Turner]

On Fri, Jan 16, 2015 at 10:44 AM, Keith Packard kei...@keithp.com wrote:
 Pass the inverse of the texture size to glamor vertex shaders so that
 we multiply by that instead of dividing by the size as multiplication
 is generally faster than division.

 Signed-off-by: Keith Packard kei...@keithp.com

Makes sense to me.

Reviewed-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 1/7] glamor: only use (un)pack_subimage when available

[Matt Turner]

On Mon, Jan 12, 2015 at 6:29 AM, Maarten Lankhorst
maarten.lankho...@ubuntu.com wrote:
 Signed-off-by: Maarten Lankhorst maarten.lankho...@ubuntu.com
 ---
  glamor/glamor.c  |  7 ++
  glamor/glamor_priv.h |  2 ++
  glamor/glamor_transfer.c | 55 
 +++-
  3 files changed, 45 insertions(+), 19 deletions(-)

 diff --git a/glamor/glamor.c b/glamor/glamor.c
 index e6e8647..f139680 100644
 --- a/glamor/glamor.c
 +++ b/glamor/glamor.c
 @@ -412,6 +412,13 @@ glamor_init(ScreenPtr screen, unsigned int flags)
  epoxy_has_gl_extension(GL_ARB_buffer_storage);
  glamor_priv-has_nv_texture_barrier =
  epoxy_has_gl_extension(GL_NV_texture_barrier);
 +glamor_priv-has_unpack_subimage =
 +glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP ||
 +epoxy_gl_version() = 30 ||
 +epoxy_has_gl_extension(GL_EXT_unpack_subimage);
 +glamor_priv-has_pack_subimage = /* not defined for GLES 2 */

You could check for NV_pack_subimage here if you care to.

 +glamor_priv-gl_flavor == GLAMOR_GL_DESKTOP ||
 +epoxy_gl_version() = 30;
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] backtrace.c: Fix word cast to a pointer

[Matt Turner]

On Mon, Jan 5, 2015 at 8:22 AM, Vicente Olivert Riera
vincent.ri...@imgtec.com wrote:
 backtrace.c uses a word size provided by libunwind. In some
 architectures like MIPS, libunwind makes that word size 64-bit for all
 variants of the architecture.

 In the lines #90 and #98, backtrace.c tries to do a cast to a pointer,
 which fails in all MIPS variants with 32-bit pointers, like MIPS32 or
 MIPS64 n32, because it's trying to do a cast from a 64-bit wide variable
 to a 32-bit pointer:

 Making all in os
 make[2]: Entering directory
 `/home/test/test/1/output/build/xserver_xorg-server-1.15.1/os'
   CC WaitFor.lo
   CC access.lo
   CC auth.lo
   CC backtrace.lo
 backtrace.c: In function 'xorg_backtrace':
 backtrace.c:90:20: error: cast to pointer from integer of different size
 [-Werror=int-to-pointer-cast]
  if (dladdr((void *)(pip.start_ip + off), dlinfo) 
 dlinfo.dli_fname 
 ^
 backtrace.c:98:13: error: cast to pointer from integer of different size
 [-Werror=int-to-pointer-cast]
  (void *)(pip.start_ip + off));
  ^
 cc1: some warnings being treated as errors
 make[2]: *** [backtrace.lo] Error 1
 make[2]: *** Waiting for unfinished jobs

 Making the cast to a pointer-sized integer, and then to a pointer fixes
 the problem.

 Related:
   https://bugs.freedesktop.org/show_bug.cgi?id=79939

 Signed-off-by: Vicente Olivert Riera vincent.ri...@imgtec.com
 ---
  os/backtrace.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/os/backtrace.c b/os/backtrace.c
 index 3d1195b..3c101ae 100644
 --- a/os/backtrace.c
 +++ b/os/backtrace.c
 @@ -87,7 +87,7 @@ xorg_backtrace(void)
  procname[1] = 0;
  }

 -if (dladdr((void *)(pip.start_ip + off), dlinfo)  
 dlinfo.dli_fname 
 +if (dladdr((void *)(long)(pip.start_ip + off), dlinfo)  
 dlinfo.dli_fname 

You should cast to the integer type that's actually specified to be
the same size as a pointer, intptr_t. That's what it's there for.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libX11] xcb_io: Fix Xlib 32-bit request number issues

[Matt Turner]

On Fri, Sep 26, 2014 at 3:40 AM, Jan Smout smout@gmail.com wrote:
 Keith Packard doesn't seem very responsive (as in 'completely ignoring the
 subject')

Perhaps you should try Ccing him? (now Cc'd)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH][V3][xserver] configure.ac: add option for xshmfence

[Matt Turner]

On Fri, Aug 15, 2014 at 8:16 AM, Keith Packard kei...@keithp.com wrote:
 Ross Burton ross.bur...@intel.com writes:

 xshmfence is usable outside of DRI3, and is currently autodetected which 
 isn't
 good for distributions where deterministic builds are desired.

 Signed-off-by: Ross Burton ross.bur...@intel.com

 Seems like this should work;

 Reviewed-by: Keith Packard kei...@keithp.com

You already pulled in a newer version of this patch (commit 4afedf545b67).
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:libXaw] Fix abs() usage.

[Matt Turner]

On Wed, Jul 16, 2014 at 9:44 AM, Thomas Klausner w...@netbsd.org wrote:
 Review please!

 Thanks,
  Thomas

Reviewed-by: Matt Turner matts...@gmail.com

Please apply to libXaw3d as well.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH][V4][xserver] configure.ac: add option for xshmfence

[Matt Turner]

Reviewed-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH][V2][xserver] configure.ac: add option for xshmfence

[Matt Turner]

On Tue, Jul 8, 2014 at 2:07 PM, Ross Burton ross.bur...@intel.com wrote:
 xshmfence is usable outside of DRI3, and is currently autodetected which isn't
 good for distributions where deterministic builds are aspired to.

Forgot to reword. s/aspired to/desired/


 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
  configure.ac |   22 +-
  1 file changed, 13 insertions(+), 9 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index c214638..a1ca9ec 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -648,6 +648,7 @@ AC_ARG_ENABLE(kdrive-kbd, 
 AS_HELP_STRING([--enable-kdrive-kbd], [Build kbd d
  AC_ARG_ENABLE(kdrive-mouse,   AS_HELP_STRING([--enable-kdrive-mouse], [Build 
 mouse driver for kdrive (default: auto)]), [KDRIVE_MOUSE=$enableval], 
 [KDRIVE_MOUSE=auto])
  AC_ARG_ENABLE(kdrive-evdev,   AS_HELP_STRING([--enable-kdrive-evdev], [Build 
 evdev driver for kdrive (default: auto)]), [KDRIVE_EVDEV=$enableval], 
 [KDRIVE_EVDEV=auto])
  AC_ARG_ENABLE(libunwind,  AS_HELP_STRING([--enable-libunwind], [Use 
 libunwind for backtracing (default: auto)]), [LIBUNWIND=$enableval], 
 [LIBUNWIND=auto])
 +AC_ARG_ENABLE(xshmfence,  AS_HELP_STRING([--disable-xshmfence], [Disable 
 xshmfence (default: auto)]), [WANT_XSHMFENCE=$enableval], 
 [WANT_XSHMFENCE=auto])

None of the other variables are prefixed with WANT_. I'd drop that.

With those two changes,

Reviewed-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH][V2][xserver] configure.ac: add option for xshmfence

[Matt Turner]

On Tue, Jul 8, 2014 at 2:23 PM, Burton, Ross ross.bur...@intel.com wrote:
 On 8 July 2014 22:14, Matt Turner matts...@gmail.com wrote:
 On Tue, Jul 8, 2014 at 2:07 PM, Ross Burton ross.bur...@intel.com wrote:
 xshmfence is usable outside of DRI3, and is currently autodetected which 
 isn't
 good for distributions where deterministic builds are aspired to.

 Forgot to reword. s/aspired to/desired/

 Done.

 +AC_ARG_ENABLE(xshmfence,  AS_HELP_STRING([--disable-xshmfence], 
 [Disable xshmfence (default: auto)]), [WANT_XSHMFENCE=$enableval], 
 [WANT_XSHMFENCE=auto])

 None of the other variables are prefixed with WANT_. I'd drop that.

 There's already a variable called XSHMFENCE containing the pkgconfig
 dependencies, and WANT_/HAVE_ make the logic obvious in my opinion.

Oh, looks like that should have been named LIBXSHMFENCE.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] configure.ac: add option for xshmfence

[Matt Turner]

On Mon, Jul 7, 2014 at 5:18 AM, Ross Burton ross.bur...@intel.com wrote:
 xshmfence is usable outside of DRI3, and is currently autodetected which isn't
 good for distributions where deterministic builds are aspired to.

s/aspired to/desired/ seems a lot less awkward.


 Signed-off-by: Ross Burton ross.bur...@intel.com
 ---
  configure.ac |   20 +++-
  1 file changed, 11 insertions(+), 9 deletions(-)

 diff --git a/configure.ac b/configure.ac
 index 2daa6be..fd1cf3f 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -648,6 +648,7 @@ AC_ARG_ENABLE(kdrive-kbd, 
 AS_HELP_STRING([--enable-kdrive-kbd], [Build kbd d
  AC_ARG_ENABLE(kdrive-mouse,   AS_HELP_STRING([--enable-kdrive-mouse], [Build 
 mouse driver for kdrive (default: auto)]), [KDRIVE_MOUSE=$enableval], 
 [KDRIVE_MOUSE=auto])
  AC_ARG_ENABLE(kdrive-evdev,   AS_HELP_STRING([--enable-kdrive-evdev], [Build 
 evdev driver for kdrive (default: auto)]), [KDRIVE_EVDEV=$enableval], 
 [KDRIVE_EVDEV=auto])
  AC_ARG_ENABLE(libunwind,  AS_HELP_STRING([--enable-libunwind], [Use 
 libunwind for backtracing (default: auto)]), [LIBUNWIND=$enableval], 
 [LIBUNWIND=auto])
 +AC_ARG_ENABLE(xshmfence,  AS_HELP_STRING([--disable-xshmfence], [Disable 
 xshmfence (default: auto)]), [WANT_XSHMFENCE=$enableval], 
 [WANT_XSHMFENCE=auto])


  dnl chown/chmod to be setuid root as part of build
 @@ -1235,18 +1236,19 @@ esac

  AM_CONDITIONAL(BUSFAULT, test x$BUSFAULT = xyes)

 -PKG_CHECK_MODULES([XSHMFENCE], $XSHMFENCE,
 - [HAVE_XSHMFENCE=yes], [HAVE_XSHMFENCE=no])
 +HAVE_XSHMFENCE=no
 +if test x$WANT_XSHMFENCE != xno; then
 +   PKG_CHECK_MODULES([XSHMFENCE], $XSHMFENCE,
 + [HAVE_XSHMFENCE=yes], [HAVE_XSHMFENCE=no])

 +   if test $WANT_XSHMFENCE,$HAVE_XSHMFENCE = yes,no; then
 +   AC_MSG_ERROR([libxshmfence requested but not found.])
 +   fi
 +   AC_DEFINE(HAVE_XSHMFENCE, 1, [Have X Shared Memory Fence library])
 +   REQUIRED_LIBS=$REQUIRED_LIBS xshmfence
 +fi

It looks like you're going to a lot of effort to avoid the
PKG_CHECK_MODULES if xshmfence is disabled. Any particular reason?

Does the pattern used for libunwind work instead?
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Fix hw/xfree86/common/compiler.h for mips64

[Matt Turner]

On Fri, Oct 11, 2013 at 10:22 PM, YunQiang Su wzss...@gmail.com wrote:
 Mark mips64 as 64bit
 Use long as PORT_SIZE

 Signed-off-by: YunQiang Su wzss...@gmail.com

Reviewed-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:libXpm] Fix abs() usage.

[Matt Turner]

On Wed, Mar 19, 2014 at 12:53 AM, Thomas Klausner w...@netbsd.org wrote:
 On Tue, Mar 18, 2014 at 06:51:28PM -0700, Matt Turner wrote:
 On Tue, Mar 18, 2014 at 2:57 PM, Thomas Klausner w...@netbsd.org wrote:
  For long arguments, use labs().
  From Jörg Sonnenberger jo...@netbsd.org
 
  Signed-off-by: Thomas Klausner w...@netbsd.org
  ---

 The author of this patch is you, according to git, but is Jörg
 Sonnenberger according to your commit message.

 Use --author= to set it properly.

 Ok, modified as suggested.
 Can I mark it as reviewed-by you?
  Thomas

Yes,

Reviewed-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:libXpm] Fix abs() usage.

[Matt Turner]

On Tue, Mar 18, 2014 at 2:57 PM, Thomas Klausner w...@netbsd.org wrote:
 For long arguments, use labs().
 From Jörg Sonnenberger jo...@netbsd.org

 Signed-off-by: Thomas Klausner w...@netbsd.org
 ---

The author of this patch is you, according to git, but is Jörg
Sonnenberger according to your commit message.

Use --author= to set it properly.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH synaptics] On clickpads with two touchpoints, try to detect clickfinger 3 actions

[Matt Turner]

On Sun, Dec 15, 2013 at 3:49 PM, Peter Hutterer
peter.hutte...@who-t.net wrote:
 Some touchpads provide BTN_TOOL_TRIPLETAP but do not track more than two
 touchpoints. For those, try to detect clickfinger3 actions as best as we can.

 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
 ---
  src/synaptics.c | 22 ++
  1 file changed, 22 insertions(+)

 diff --git a/src/synaptics.c b/src/synaptics.c
 index e391a98..a421384 100644
 --- a/src/synaptics.c
 +++ b/src/synaptics.c
 @@ -2510,6 +2510,28 @@ clickpad_guess_clickfingers(SynapticsPrivate * priv,
  close_point = 1;
  }

 +/* Some trackpads touchpad only track two touchpoints but announce
 +   BTN_TOOL_TRIPLETAP (which sets hw-numFingers to 3).
 +   This can affect clickfingers, in the following ways:
 +   * one finger down: normal click
 +   * two fingers down, close together: 2 finger click
 +   * two fingers down, apart: normal click
 +   * three fingers down, close together: 3 finger click
 +   * three fingers down, with two grouped next to each other: should be
 +   * 2-finger click but we can't detect this.
 +   * so: if two detected fingers are close together and HW says three
 +   * fingers, make it three fingers.
 +   * if two detected fingers are apart and HW says three fingers, make
 +   * it a two-finger click, guessing that the third finger is somewhere
 +   * close to another finger.
 +   */
 +if (hw-numFingers = 3  nfingers  hw-numFingers) {
 +if (!nfingers) /* touchpoints too far apart apart */

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

Re: Build broken: _XSERVTrans\(Send\)\|\(Recv\)Fd

[Matt Turner]

On Sun, Nov 10, 2013 at 1:44 AM, Knut Petersen
knut_peter...@t-online.de wrote:
 A full xorg build fails here during building of the xserver:

 xserver version: ab4b1fb38a61feb73d8336cc7a3399eb9d3d25be

 make[5]: Leaving directory `/home/knut/fast/xorg/xserver/hw/xfree86/dixmods'
   CCLD Xorg
 ../../os/.libs/libos.a(io.o): In function `ReadFdFromClient':
 io.c:(.text+0x2a): undefined reference to `_XSERVTransRecvFd'
 ../../os/.libs/libos.a(io.o): In function `WriteFdToClient':
 io.c:(.text+0x86d): undefined reference to `_XSERVTransSendFd'
 collect2: error: ld returned 1 exit status
 make[4]: *** [Xorg] Fehler 1
 make[4]: Leaving directory `/home/knut/fast/xorg/xserver/hw/xfree86'
 make[3]: *** [all-recursive] Fehler 1
 make[3]: Leaving directory `/home/knut/fast/xorg/xserver/hw/xfree86'
 make[2]: *** [all] Fehler 2
 make[2]: Leaving directory `/home/knut/fast/xorg/xserver/hw/xfree86'
 make[1]: *** [all-recursive] Fehler 1
 make[1]: Leaving directory `/home/knut/fast/xorg/xserver/hw'
 make: *** [all-recursive] Fehler 1
 build.sh: make  failed on xserver
 build.sh: error processing:  xserver

We're waiting on Keith to push the fixes from the master branch of his
tree. One of them fixes it.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Please pick fd1b24a93e to 1.14

[Matt Turner]

Hi Matt,

Please cherry-pick fd1b24a93e (glx: Add support for the new DRI
loader entrypoint.) to the server-1.14-branch. It picks cleanly and
is needed to load the classic DRI drivers in Mesa 10 which is going to
be branched tomorrow and released at the end of November, a month
before xserver-1.15.

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

Re: Donation of ARM CubieTruck to anyone interested in developing Xorg for ARM

[Matt Turner]

On Sat, Nov 2, 2013 at 9:32 AM, Luc Verhaegen l...@skynet.be wrote:
 On Sat, Nov 02, 2013 at 06:28:10PM +0200, Alexey Eromenko wrote:
 The people at sunxi ML probably already have Allwinner-based products.
 Sending them a cubietruck won't change much.

 Are you telling us that we are doing such a terrible job that you feel
 the need to try to create communities somewhere else?

Holy crap, Luc. The guy is just offering free hardware.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH modular] build.sh: add presentproto, dri3proto, and libxshmfence

[Matt Turner]

On Fri, Nov 1, 2013 at 1:37 PM, Gaetan Nadon mems...@videotron.ca wrote:
 I am out of context here, but these looks like prototypes from a packaging
 point of view. Could you bring them up to spec? Any other xorg protos and
 libs can be used to copy and fix up. Otherwise it would take dozens of
 patches to fix them up.

Aaron's just reporting that new packages are required by the X Server.
They're all new packages Keith needs/wrote for DRI3 support.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] X.Org minimum requirements for Autotools policy review

[Matt Turner]

On Fri, Oct 25, 2013 at 8:13 AM, Gaetan Nadon mems...@videotron.ca wrote:
 Speaking of Mesa, you may be concerned that part of Mesa source code is
 GPL v3. I suppose it taints xorg which links to mesa. That was another
 question I had.

The only thing I see in Mesa is ralloc.h, which lists LGPLv3, but I
think it's a mistake. I'll check into it.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] X.Org minimum requirements for Autotools policy review

[Matt Turner]

On Fri, Oct 25, 2013 at 10:51 AM, Matt Turner matts...@gmail.com wrote:
 On Fri, Oct 25, 2013 at 8:13 AM, Gaetan Nadon mems...@videotron.ca wrote:
 Speaking of Mesa, you may be concerned that part of Mesa source code is
 GPL v3. I suppose it taints xorg which links to mesa. That was another
 question I had.

 The only thing I see in Mesa is ralloc.h, which lists LGPLv3, but I
 think it's a mistake. I'll check into it.

Ah, missing some context:

/*
 * The talloc implementation is available under the GNU Lesser
 * General Public License (GNU LGPL), version 3 or later. It is
 * more sophisticated than ralloc in that it includes reference
 * counting and debugging features. See: http://talloc.samba.org/
 */
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xf86-video-neomagic] Unbreak shadowfb initialization with modern X servers.

[Matt Turner]

On Thu, Jun 13, 2013 at 2:38 PM, Matthieu Herrb matthieu.he...@laas.fr wrote:
 Signed-off-by: Matthieu Herrb matthieu.he...@laas.fr
 ---

Thanks, this fixes https://bugs.gentoo.org/show_bug.cgi?id=434468 so
I've applied it and pushed a new release (1.2.8).

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

Re: [PATCH pixman] '+=' is not a valid POSIX shell operator.

[Matt Turner]

On Sat, Jun 8, 2013 at 9:07 AM, Matthieu Herrb matthieu.he...@laas.fr wrote:
 Signed-off-by: Matthieu Herrb matthieu.he...@laas.fr
 ---
  configure.ac | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git configure.ac configure.ac
 index 221179f..b36298a 100644
 --- configure.ac
 +++ configure.ac
 @@ -616,7 +616,7 @@ AC_ARG_ENABLE(arm-iwmmxt2,
  if test x$IWMMXT_CFLAGS = x ; then
 IWMMXT_CFLAGS=-flax-vector-conversions -Winline -march=iwmmxt
 if test $enable_iwmmxt2 != no ; then
 -  IWMMXT_CFLAGS+=2
 +  IWMMXT_CFLAGS=${IWMMXT_CFLAGS}2
 fi
  fi

 --
 1.8.3

Thanks, I've committed this with a revised commit title of
configure.ac: Don't use '+=' since it's not POSIX

pixman patches go to its own list, pix...@lists.freedesktop.org.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH:xf86-video-glint] when doing DDC2 on Permedia2 make sure to clear the USE_MONID bit in the DDCdata register so the i2c bits actually do something Now DDC2 works on my PGX32 / Raptor 8P

[Matt Turner]

On Sun, Jun 2, 2013 at 2:41 PM, Thomas Klausner w...@netbsd.org wrote:
 From Michael Lorez macal...@netbsd.org
 ---
  src/pm2_dac.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

 diff --git a/src/pm2_dac.c b/src/pm2_dac.c
 index 85093ff..b6771a5 100644
 --- a/src/pm2_dac.c
 +++ b/src/pm2_dac.c
 @@ -458,8 +458,14 @@ Permedia2I2CPutBits(I2CBusPtr b, int scl, int sda)
  {
  GLINTPtr pGlint = (GLINTPtr) b-DriverPrivate.ptr;
  int r = (pGlint-DDCBus == b) ? PMDDCData : VSSerialBusControl;
 +/*
 +This is bogus.
 +All this line does is to preserve the USE_MONID bit if set which prevents
 +the i2c bits from doing anything
  CARD32 v = GLINT_READ_REG(r)  ~(ClkOut | DataOut);
 -
 +*/
 +CARD32 v = 0;
 +

Not sure I like just commenting out code like this.

Fix the commit title and summary message.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Where is the function xf1bppScreenInit()?

[Matt Turner]

On Thu, Apr 25, 2013 at 1:55 AM, ZHANG Zhaolong zhangzl2...@126.com wrote:
 Hi all,

 I am reading xf86-video-vga-4.0.0.5 source code. It shows that:
 if (pGenericPriv-ShadowFB)
 call fbScreeInit();
 else
 call xf1bppScreenInit();

 The same flow is in xf86-video-cirrus-1.3.2 too.

 But where is the function xf1bppScreenInit()?

 I searched in xorg-server-1.13.2.902, but didn't find the definition.

 Best regards.
 --
 ZHANG Zhaolong

Alan and Aaron already answered these questions.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH util/modular 2/7] xorg.modules: mesa is now autotooled

[Matt Turner]

On Thu, Feb 28, 2013 at 7:41 AM, Dan Nicholson dbn.li...@gmail.com wrote:
 Are all the old Makefiles (which require
 makedepend) removed at this point?

Yes, except for apple-glx.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: xserver 1.13.3 nomination window is open

[Matt Turner]

On Mon, Feb 11, 2013 at 7:36 PM, Matt Dew mar...@osource.org wrote:
 Acked and pulled c160...58aa

Those shas are too short to look up.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH] compiler.h: Remove dead STANDALONE_MMIO

[Matt Turner]

The only drivers I can find that used this are the r128 and radeon DRI
drivers. r128 is dead and the radeon driver wasn't including Xorg's
compiler.h and still worked.
---
 hw/xfree86/common/compiler.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/hw/xfree86/common/compiler.h b/hw/xfree86/common/compiler.h
index c980bee..3a8240b 100644
--- a/hw/xfree86/common/compiler.h
+++ b/hw/xfree86/common/compiler.h
@@ -1519,18 +1519,7 @@ inl(unsigned short port)
 /* entry points for Mmio memory access routines */
 extern _X_EXPORT int (*xf86ReadMmio8) (void *, unsigned long);
 extern _X_EXPORT int (*xf86ReadMmio16) (void *, unsigned long);
-
-#ifndef STANDALONE_MMIO
 extern _X_EXPORT int (*xf86ReadMmio32) (void *, unsigned long);
-#else
-/* Some DRI 3D drivers need MMIO_IN32. */
-static __inline__ int
-xf86ReadMmio32(void *Base, unsigned long Offset)
-{
-mem_barrier();
-return *(volatile unsigned int *) ((unsigned long) Base + (Offset));
-}
-#endif
 extern _X_EXPORT void (*xf86WriteMmio8) (int, void *, unsigned long);
 extern _X_EXPORT void (*xf86WriteMmio16) (int, void *, unsigned long);
 extern _X_EXPORT void (*xf86WriteMmio32) (int, void *, unsigned long);
@@ -1545,11 +1534,7 @@ extern _X_EXPORT void xf86SlowBCopyToBus(unsigned char 
*, unsigned char *, int);
 /* Changed to kill noise generated by gcc's -Wcast-align */
 #define MMIO_IN8(base, offset) (*xf86ReadMmio8)(base, offset)
 #define MMIO_IN16(base, offset) (*xf86ReadMmio16)(base, offset)
-#ifndef STANDALONE_MMIO
 #define MMIO_IN32(base, offset) (*xf86ReadMmio32)(base, offset)
-#else
-#define MMIO_IN32(base, offset) xf86ReadMmio32(base, offset)
-#endif
 
 #define MMIO_OUT32(base, offset, val) \
 do { \
-- 
1.7.12.4

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

Re: [PATCH] compiler.h: Remove dead STANDALONE_MMIO

[Matt Turner]

On Thu, Feb 7, 2013 at 5:29 PM, Matt Turner matts...@gmail.com wrote:
 The only drivers I can find that used this are the r128 and radeon DRI
 drivers. r128 is dead and the radeon driver wasn't including Xorg's
 compiler.h and still worked.
 ---

Oh, and

Signed-off-by: Matt Turner matts...@gmail.com
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xorg-gtest 01/11] Drop .gz tarballs, bz2 is enough

[Matt Turner]

On Mon, Nov 12, 2012 at 2:01 PM, Ángel González inge...@zoho.com wrote:
 On 09/11/12 05:58, Matt Turner wrote:
 Perhaps the bigger advantage of xz over bz2 is decompression speed. In
 many cases, single threaded xz decompression is faster than
 two-threaded parallel bz2 decompression.

 What do you mean by two-threaded parallel bz2 decompression ?
 I don't think it can be done in what I'd call the traditional meaning
 (taking a random file compressed with bzip2(1) and decompressing faster
 by using two threads instead of one)...

I mean using lbzip2: https://github.com/kjn/lbzip2/
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel