Re: [PATCH] xf86RandR12: use correct gamma size when allocating gamma table
db...@chromium.org writes: > From: Dominik Behr > > When setting crtc->gamma_size to randr_crtc->gammaSize we should > use randr_crtc->gammaSize to allocate new gamma table in crtc. > Currently, if randr_crtc->gammaSize > crtc->gammaSize the subsequent > memcpy will overwrite memory beyond the end of gamma table. Merged. 35d275c..70e5641 master -> master -- keith.pack...@intel.com pgpiTxhcAkGpg.pgp Description: PGP signature ___ 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] Revert "xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP"
On Mon, Apr 21, 2014 at 10:24:34PM -0700, Keith Packard wrote: > Peter Hutterer writes: > > > This was the wrong fix to the problem, and it triggered a change in XKB > > behavior: previously a button event would unlock a latched modifier, now it > > doesn't anymore. > > https://bugs.freedesktop.org/show_bug.cgi?id=73155 > > I haven't merged this as I'm expecting to see it in a future pull > request from you. I can merge it separately if you like though, of > course. It was in my last pull, already in master, so no need for any further action. thanks though. 98924719d524bf87cdf301063cd744d1271c33ff Cheers, Peter ___ 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] Revert "xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP"
Peter Hutterer writes: > This was the wrong fix to the problem, and it triggered a change in XKB > behavior: previously a button event would unlock a latched modifier, now it > doesn't anymore. > https://bugs.freedesktop.org/show_bug.cgi?id=73155 I haven't merged this as I'm expecting to see it in a future pull request from you. I can merge it separately if you like though, of course. -- keith.pack...@intel.com pgp5TT3FEUOOv.pgp Description: PGP signature ___ 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] hw/xwin: link dynamically and export symbols
"Yaakov (Cygwin/X)" writes: > From: Yaakov Selkowitz > > With my patch to fix shared libXfont to work correctly on Cygwin/Win32, > there is no need for -static anymore. But, XWin.exe must export its > symbols in order for them to override libXfont's stubs. I don't think there's a libXfont released with this yet? -- keith.pack...@intel.com pgpm6l_JsH0IK.pgp Description: PGP signature ___ 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: Add -displayfd into -help text
Robert Ancell writes:
> ErrorF("-cc intdefault color visual class\n");
> ErrorF("-nocursor disable the cursor\n");
> ErrorF("-core generate core dump on fatal error\n");
> +ErrorF("-displayfd fd file descriptor to write display
> number to when ready to connect\n");
You'll need to fix your email program to not mangle patches...
--
keith.pack...@intel.com
pgprohM_XzTd4.pgp
Description: PGP signature
___
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 2/2] glxproxy: Fix memory leak on error path in CreateGLXPixmap (#50281)
Adam Jackson writes:
> Signed-off-by: Adam Jackson
> ---
> hw/dmx/glxProxy/glxcmds.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glxProxy/glxcmds.c
> index 964db40..f097906 100644
> --- a/hw/dmx/glxProxy/glxcmds.c
> +++ b/hw/dmx/glxProxy/glxcmds.c
> @@ -2017,6 +2017,7 @@ CreateGLXPixmap(__GLXclientState * cl,
> }
>
> if (!(AddResource(glxpixmapId, __glXPixmapRes, pGlxPixmap))) {
> +free(pGlxPixmap->be_xids);
> free(pGlxPixmap);
> return BadAlloc;
> }
I think you missed a return path about 8 lines before this:
else {
client->errorValue = (visual ? visual : fbconfigId);
free(pGlxPixmap);
return BadValue;
}
XFlush(dpy);
}
if (!(AddResource(glxpixmapId, __glXPixmapRes, pGlxPixmap))) {
free(pGlxPixmap);
return BadAlloc;
}
--
keith.pack...@intel.com
pgpgWoEj1xjrr.pgp
Description: PGP signature
___
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: Initialize the set of signals to be suppressed during our handler.
Eric Anholt writes: > Fixes a valgrind complaint: > > ==8805== Syscall param rt_sigaction(act->sa_mask) points to uninitialised > byte(s) > ==8805==at 0x5EB8315: __libc_sigaction (sigaction.c:66) > ==8805==by 0x5B13DA: busfault_init (busfault.c:145) > ==8805==by 0x5A60A2: OsInit (osinit.c:191) > ==8805==by 0x46EBA2: dix_main (main.c:163) > > Signed-off-by: Eric Anholt Merged. 19e5a13..35d275c master -> master -- keith.pack...@intel.com pgpBEceO1rRcY.pgp Description: PGP signature ___ 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
YunQiang Su writes: > Mark mips64 as 64bit > Use long as PORT_SIZE Merged. 8daeaa2...19e5a13 master -> master -- keith.pack...@intel.com pgpFnb9_y1it_.pgp Description: PGP signature ___ 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] xres: Fix size estimation for <8bpp pixmaps (#69057)
Adam Jackson writes: > Just use floats, it's not like this is a performance path. > > Signed-off-by: Adam Jackson Merged. 5df6682..f466fb2 master -> master -- keith.pack...@intel.com pgp0YvVLIIx9v.pgp Description: PGP signature ___ 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] Add a return value to set_cursor_position() to allow it to report failure
Michael Thayer writes: > set_cursor_position() may need to be able to fail and have the server fall > back to a software cursor in at least the situation in which we are running > on virtual hardware and using the host cursor as a hardware cursor for the > guest but cannot change its position. Frankly, the usual "solution" for nested or virtual X servers is to just ignore the cursor position assignment. -- keith.pack...@intel.com pgp1m3Gydh17r.pgp Description: PGP signature ___ 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] linux: Propagate failure up to xf86MapVidMem (#18304)
Adam Jackson writes: > As opposed to calling FatalError. Hrm. This is effectively and ABI change as mapVidMem would otherwise not return on an error. While it might be nice and allow drivers to do something sensible, I'm afraid I can't take it for 1.16 because drivers may not be prepared to handle the error case. -- keith.pack...@intel.com pgpnfYZKxUvER.pgp Description: PGP signature ___ 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] linux: Propagate failure up to xf86MapVidMem (#18304)
walter harms writes: > this looks strange, what fd is checked in case open(DEV_MEM,... is > never called ? You're just seeing part of the #if, which is opening DEV_MEM in both paths, once with O_SYNC and once without it (the O_SYNC path is never taken as it's #if 0) -- keith.pack...@intel.com pgpUBbKi1h6T0.pgp Description: PGP signature ___ 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] xfixes: Forbid manipulating clip for source-only pictures (#28968)
Adam Jackson writes: > Just throw BadPicture instead of crashing. It's not currently a > meaningful thing to do anyway, RenderSetPictureRectangles would error if > you tried (which this patch changes to BadPicture as well for > consistency). The problem with trying to do it is if the clip is > specified as a pixmap then we try to convert it to a region, and > ->BitmapToRegion requires a ScreenPtr, and source-only pictures don't > have one. And source-only pictures can't get a CT_PIXMAP set -- CPClipMask returns BadDrawable when you try to do that on a picture without a drawable. If you saw this in real life, then you'd have found a bug in the server elsewhere and we'll want to track that down... If it were possible to set a bitmap clip on a source-only picture, then a trivial fix would be to pull the screen out of the bitmap. In any case, Nak'd-by: Keith Packard -- keith.pack...@intel.com pgptBw0lXYBKI.pgp Description: PGP signature ___ 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] shadowfb: Port to miext/damage (#31303, #65547)
Keith Packard writes: > Adam Jackson writes: > >> Somewhat shocking how much simpler this is, isn't it? We no longer need >> to wrap the screen or GC or Picture, because damage does it for us, >> which is doubly great since the old shadowfb code didn't wrap _enough_ >> things (border updates and Render glyphs, at least). The only real >> difference now between this and shadow is a) shadow will let you track >> arbitrary pixmaps, and b) shadow's update hook runs off the BlockHandler >> whereas shadowfb is immediate. > > Reviewed and merged. >8edeac2..2dcb167 master -> master But I didn't even remember to run 'make' -- it didn't even build. I've pushed fixes to make it compile. Please let me know if I've broken it... 2dcb167..5df6682 master -> master -- keith.pack...@intel.com pgpeTZiiYmbkY.pgp Description: PGP signature ___ 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] shadowfb: Port to miext/damage (#31303, #65547)
Adam Jackson writes: > Somewhat shocking how much simpler this is, isn't it? We no longer need > to wrap the screen or GC or Picture, because damage does it for us, > which is doubly great since the old shadowfb code didn't wrap _enough_ > things (border updates and Render glyphs, at least). The only real > difference now between this and shadow is a) shadow will let you track > arbitrary pixmaps, and b) shadow's update hook runs off the BlockHandler > whereas shadowfb is immediate. Reviewed and merged. 8edeac2..2dcb167 master -> master -- keith.pack...@intel.com pgp2RKs_DXGOq.pgp Description: PGP signature ___ 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: Add remaining header files to SOURCES
Michel Dänzer writes: > From: Michel Dänzer > > It wasn't possible to build glamor from tarballs. Merged. (sorry, the patch IDs are lost in the mists of time for this push) -- keith.pack...@intel.com pgpc__kfiYE5Z.pgp Description: PGP signature ___ 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: glamor versus AIGLX GL context series
On 22.04.2014 04:08, Eric Anholt wrote:
> Michel Dänzer writes:
>>
>> By changing the context, it may also invalidate the DRI2 buffer information,
>> so we need to get that again.
>>
>> Fixes crashes due to use-after-free with LIBGL_ALWAYS_INDIRECT=1 glxgears
>> and piglit.
>
> Glad to see things are working for you. I've added it to the series.
Thanks, but the Git author e-mail address is wrong in your tree.
> If we can get this and the render change reviewed,
For the glamor-glx-context-2 branch (minus glamor-fixes), apart from the
issues noted below:
Reviewed-by: Michel Dänzer
> I think the must-do items for glamor in 1.16 will be done.
As I mentioned before, there's also at least one fix for a memory leak
in copy_n_to_n that needs to be ported from the standalone glamor tree,
if Keith's copy_n_to_n rework doesn't go into 1.16. There may be more
fixes to be ported from there; are you planning to take a look at that,
or should I?
BTW, the 'glamor: Add glamor_transfer based glamor_get_image and
glamor_put_image' commit in your glamor-fixes branch still breaks the
libreoffice icons for me. Are you guys seeing that as well?
Also, the current glamor-gl-context-2 branch fails to build for me,
because glamor_image.c still uses glamor_{get,put}_context().
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
signature.asc
Description: OpenPGP digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] composite: Fix memory leak in compCopyWindow
Peter Harris writes: > Signed-off-by: Peter Harris Merged. -- keith.pack...@intel.com pgp9aGj12lCyM.pgp Description: PGP signature ___ 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 0/3] GLX fixes for indirect contexts
Jon TURNEY writes: > Fixes for a few problems with GLX and indirect contexts. > > I can reproduce [1/3] and [2/3] on X server 1.15.1, mesa 10.1.0 (from Ubuntu > 14.04), but not on X server 1.14.5 mesa 9.2.1 (from Ubuntu 13.10), so these > are > probably regressions in 1.15 and may be candidates for that branch. > > Jon TURNEY (3): > Revert "glx: Simplify glXDestroyContext" > glx: Flush context which is being made non-current due to drawable > going away > glx: Fix crash when a client exits without deleting GL contexts I'd love to have Adam take a look at these and see if they seem reasonable enough. -- keith.pack...@intel.com pgp3ied2vUFeF.pgp Description: PGP signature ___ 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-input-synaptics] Fix product ID cutoff for MODEL_APPLETOUCH/MODEL_UNIBODY_MACBOOK
Macbook 3,1, Macbook 4,1 (not Air). First reported in Ubuntu 13.10 from what
I've seen. This makes sense as the problematic change appears to have been
introduced between 1.6.3 and 1.7.1, which was the version jump between 13.04
and 13.10.
http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/src/synaptics.c?id=0e222876d7da7acbaaf955c2e7b7efdf3549bde9
http://launchpadlibrarian.net/145837828/xserver-xorg-input-synaptics_1.6.3-0ubuntu1.1_1.7.1-0ubuntu1.diff.gz
See also:
http://lists.x.org/archives/xorg/2014-February/056386.html
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/1246215
My Macbook 3,1 reports as 0x229. Around the web I've seen devices report as
0x22a that also use the old appletouch kernel driver. This is what I'm basing
the shift on. You could potentially check the actual kernel driver being used
instead (appletouch vs bcm5974) and load defaults based on that, but this would
likely be a nontrivial change.
As for why it hasn't caused much of a fuss, the bug only hit the *buntus about
6 months ago and technically-apt users will often figure out how to work around
it with synclient etc. I'd expect this to affect more people in the near future
as Apple begins to drop support for the versions of OS X these devices are
capable of running, and more users begin to migrate, many of whom won't be as
technically-apt as early adopters.
- Clinton
On 04/21/2014 08:30 PM, Peter Hutterer wrote:
> On Sat, Apr 19, 2014 at 10:23:00PM -0500, Clinton Sprain wrote:
>> A handful of Macbooks are being tagged as MODEL_UNIBODY_MACBOOKs when they
>> should not be. This causes the default sensitivity to be very low for them,
>> making the touchpad very difficult to use. This change moves the product ID
>> cutoff so those devices fall into the old bucket again.
>
> just to confirm: which one of those do you have or did you see the bug
> reported on? Looking at the kernel's ID collection this change only affects
> first-gen macbook airs and should've been an issue for roughly two years
> already.
>
> Which again makes me wonder: what change exposed this bug recently?
>
> Cheers,
>Peter
>
>> src/eventcomm.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/eventcomm.c b/src/eventcomm.c
>> index 858efeb..405eeb9 100644
>> --- a/src/eventcomm.c
>> +++ b/src/eventcomm.c
>> @@ -305,8 +305,8 @@ struct model_lookup_t {
>> static struct model_lookup_t model_lookup_table[] = {
>> {0x0002, 0x0007, 0x0007, MODEL_SYNAPTICS},
>> {0x0002, 0x0008, 0x0008, MODEL_ALPS},
>> -{0x05ac, PRODUCT_ANY, 0x222, MODEL_APPLETOUCH},
>> -{0x05ac, 0x223, PRODUCT_ANY, MODEL_UNIBODY_MACBOOK},
>> +{0x05ac, PRODUCT_ANY, 0x22f, MODEL_APPLETOUCH},
>> +{0x05ac, 0x230, PRODUCT_ANY, MODEL_UNIBODY_MACBOOK},
>> {0x0002, 0x000e, 0x000e, MODEL_ELANTECH},
>> {0x0, 0x0, 0x0, 0x0}
>> };
>> --
>> 1.9.1
___
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] dmxConfigCanvasUpdate: Delay dereference until after checking for NULL
Alan Coopersmith writes: > Flagged by cppcheck 1.64: > [hw/dmx/config/xdmxconfig.c:306] -> [hw/dmx/config/xdmxconfig.c:323]: > (warning) Possible null pointer dereference: fs - otherwise >it is redundant to check it against null. > > Signed-off-by: Alan Coopersmith Reviewed and merged: 983e303..935ea0d master -> master -- keith.pack...@intel.com pgpP0y4RuqUcQ.pgp Description: PGP signature ___ 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: Fix accelerated rendering of GTK's ARGB vs xBGR composites.
Eric Anholt writes: > There is some complicated code to support tweaking the format as we > upload from a SHM pixmap (aka the GTK icon cache), but if we weren't > sourcing from a SHM pixmap we just forgot to check that the formats > matched at all. > > We could potentially be a little more discerning here (xRGB source and > ARGB mask would be fine, for example), but this will all change with > texture views anyway, so just get the rendering working for 1.16 > release. > > Fixes the new rendercheck gtk_argb_xbgr test. > > v2: Squash in keithp's fix for checking that we have a non-NULL > pixmap, and reword the comment even more. Reviewed-by: Keith Packard (please send along a Signed-off-by: line and I'll merge this in) -- keith.pack...@intel.com pgpIuV7myKrof.pgp Description: PGP signature ___ 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] fb: Fix origin of source picture in fbGlyphs
Peter Harris writes: > On 2014-04-21 18:20, Keith Packard wrote: >> Peter Harris writes: >> >>> If a source picture doesn't repeat and a mask format is specified, the >>> incorrect calulation of the origin of the glyphs caused the glyphs to >>> not be drawn at all. >>> >>> Noticed when running gtk-demo from RHEL 6.5 and selecting "Rotated >>> Text". >> >> Can you explain a bit more about how to reproduce this? I'm running the >> gtk+2.0 gtk-demo app from the gtk2.0-examples debian package and not >> seeing anything obviously incorrect? > > RHEL is about the only distribution us Debian users can call "outdated" > with a straight face. > > Recent gtk-demo uses a solid (or at least repeating) source picture. The > older gtk-demo used a non-repeating source picture with a width and > height equal to that of the rotated text. I think the older gtk-demo is > the only app I've ever seen in the wild that uses a non-repeating source > picture. > > I just whipped up a minimal example; see attached. With miGlyphs (eg. > before 9cbcb5bd6a5360a128d15b77a02d8d3351f74366) it draws a green X in > the middle of the window. With fbGlyphs (before my patch), the window > stays blank. I've merged your fix and added your test app to the commit message so that the next time we find that this is broken, we can make sure the fix doesn't break this case again... Who would have thought that with the only coordinate transform available being translation that we'd have so many bugs because of it... ea15f8b..983e303 master -> master -- keith.pack...@intel.com pgpUdinJUQw8E.pgp Description: PGP signature ___ 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] Add a command line argument for disabling indirect GLX.
Eric Anholt writes: > The attack surface for indirect GLX is huge, and it's of no use to > most people (if you get an indirect GL context, you're better served > by a immediate X error than actually trying to use an indirect GL > context and finding out that it doesn't support doing anything you > want, slowly). This flag gives you a chance to disable indirect GLX > in environments where you just don't need it. > > I put in both the '+' and '-' arguments right now, so that it's easy > to patch the value to change the default policy. Not proud enough of this to add a Signed-off-by? -- keith.pack...@intel.com pgp9KBEexM3L5.pgp Description: PGP signature ___ 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] fb: Fix origin of source picture in fbGlyphs
Peter Harris writes: > If a source picture doesn't repeat and a mask format is specified, the > incorrect calulation of the origin of the glyphs caused the glyphs to > not be drawn at all. > > Noticed when running gtk-demo from RHEL 6.5 and selecting "Rotated > Text". > > Signed-off-by: Peter Harris Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpeW7gEw9GiC.pgp Description: PGP signature ___ 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-input-synaptics] Fix product ID cutoff for MODEL_APPLETOUCH/MODEL_UNIBODY_MACBOOK
On Sat, Apr 19, 2014 at 10:23:00PM -0500, Clinton Sprain wrote:
> A handful of Macbooks are being tagged as MODEL_UNIBODY_MACBOOKs when they
> should not be. This causes the default sensitivity to be very low for them,
> making the touchpad very difficult to use. This change moves the product ID
> cutoff so those devices fall into the old bucket again.
just to confirm: which one of those do you have or did you see the bug
reported on? Looking at the kernel's ID collection this change only affects
first-gen macbook airs and should've been an issue for roughly two years
already.
Which again makes me wonder: what change exposed this bug recently?
Cheers,
Peter
> src/eventcomm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/eventcomm.c b/src/eventcomm.c
> index 858efeb..405eeb9 100644
> --- a/src/eventcomm.c
> +++ b/src/eventcomm.c
> @@ -305,8 +305,8 @@ struct model_lookup_t {
> static struct model_lookup_t model_lookup_table[] = {
> {0x0002, 0x0007, 0x0007, MODEL_SYNAPTICS},
> {0x0002, 0x0008, 0x0008, MODEL_ALPS},
> -{0x05ac, PRODUCT_ANY, 0x222, MODEL_APPLETOUCH},
> -{0x05ac, 0x223, PRODUCT_ANY, MODEL_UNIBODY_MACBOOK},
> +{0x05ac, PRODUCT_ANY, 0x22f, MODEL_APPLETOUCH},
> +{0x05ac, 0x230, PRODUCT_ANY, MODEL_UNIBODY_MACBOOK},
> {0x0002, 0x000e, 0x000e, MODEL_ELANTECH},
> {0x0, 0x0, 0x0, 0x0}
> };
> --
> 1.9.1
___
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] Fix buffer read overrun
Always using strlen(s); should be fine. The compiler will optimize it out for a literal string anyway. On Fri, Apr 18, 2014 at 4:39 PM, Keith Packard wrote: > Alan Coopersmith writes: > > > They work, as long as you only ever pass a literal string to them, not a > > pointer. > > Right, but there's no type safety in that. > > > Seems like a reasonable simplification in the server - hard to use from > other > > modules (libXfont, drivers, etc.) until you're sure you'll only ever be > used > > with a server recognizing that. > > So, presumably a macro in some convenient header file would still be > useful for external consumers. > > -- > keith.pack...@intel.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 > -- Jasper ___ 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 1/6] eventcomm: drop superflous helper function
On Fri, Apr 18, 2014 at 11:55:24AM +0200, Hans de Goede wrote:
> Hi,
>
> On 04/09/2014 03:47 AM, Peter Hutterer wrote:
> > last_mt_vals_slot is only used in one location and there we can just use
> > cur_slot
> >
> > Signed-off-by: Peter Hutterer
>
> Series looks good, series is:
>
> Reviewed-by: Hans de Goede
>
> One remark about patches 5/6 and 6/6, in the mean time we've gotten
> more pnp-ids / dmi strings, so you may wish to add those too and
> squash them in.
>
> I've been keeping a little text file with up2date info on these
> laptops, I've attached it to this mail.
>
> Note the T430u does not have top buttons, it is in the file
> because it too advertises wrong min values.
thanks, I've merged the missing ones into the fdi file, squashed it together
and pushed
it. so 5/6 and 6/6 are now a single patch only, I felt lazy.
Cheers,
Peter
> > ---
> > src/eventcomm.c | 12 +---
> > 1 file changed, 1 insertion(+), 11 deletions(-)
> >
> > diff --git a/src/eventcomm.c b/src/eventcomm.c
> > index 858efeb..5030150 100644
> > --- a/src/eventcomm.c
> > +++ b/src/eventcomm.c
> > @@ -110,16 +110,6 @@ EventProtoDataAlloc(int fd)
> > return proto_data;
> > }
> >
> > -static int
> > -last_mt_vals_slot(const SynapticsPrivate * priv)
> > -{
> > -struct eventcomm_proto_data *proto_data =
> > -(struct eventcomm_proto_data *) priv->proto_data;
> > -int value = proto_data->cur_slot;
> > -
> > -return value < priv->num_slots ? value : -1;
> > -}
> > -
> > static void
> > UninitializeTouch(InputInfoPtr pInfo)
> > {
> > @@ -549,7 +539,7 @@ EventProcessTouchEvent(InputInfoPtr pInfo, struct
> > SynapticsHwState *hw,
> > proto_data->cur_slot = ev->value;
> > }
> > else {
> > -int slot_index = last_mt_vals_slot(priv);
> > +int slot_index = proto_data->cur_slot;
> >
> > if (slot_index < 0)
> > return;
> >
> dmi pnp-id range Firmware id
> Thinkpad T430uLEN0051 {1254, 5702, 1228, 4714}*
> Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd004a3/0x940300/0x126c00,
> board id: 2228, fw id: 1323666
>
> ThinkPad Helix* LEN0033 {1024, 5052, 2258, 4832}
>
> ThinkPad X240*LEN0035 {1232, 5710, 1156, 4696}
> ThinkPad S1 Yoga LEN0042 {1232, 5710, 1156, 4696}
>
> ThinkPad T431*LEN0034 {1024, 5112, 2024, 4832}
> ThinkPad L440*LEN2004 {1024, 5112, 2024, 4832}
> Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x127c00,
> board id: 2722, fw id: 1484859
> ThinkPad T440*LEN0036 {1024, 5112, 2024, 4832}
> ThinkPad L540 LEN2004 {1024, 5112, 2024, 4832}Touchpad model:
> 1, fw: 8.1, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x127c00, board id: 2722, fw
> id: 1484859
> ThinkPad T540*LEN0034 {1024, 5056, 2058, 4832} **
> Touchpad model: 1, fw: 8.1, id: 0x1e2b1, caps: 0xd001a3/0x940300/0x127c00,
> board id: 2722, fw id: 1484859
> ThinkPad X1 Carbon 2nd* LEN0034 {1024, 5112, 2024, 4832}
>
> * We don't have a quirk for this one in the kernel
> ** Should very likely be the same as all the others with a LEN0034 pnp-id
___
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: Fix accelerated rendering of GTK's ARGB vs xBGR composites.
There is some complicated code to support tweaking the format as we
upload from a SHM pixmap (aka the GTK icon cache), but if we weren't
sourcing from a SHM pixmap we just forgot to check that the formats
matched at all.
We could potentially be a little more discerning here (xRGB source and
ARGB mask would be fine, for example), but this will all change with
texture views anyway, so just get the rendering working for 1.16
release.
Fixes the new rendercheck gtk_argb_xbgr test.
v2: Squash in keithp's fix for checking that we have a non-NULL
pixmap, and reword the comment even more.
---
glamor/glamor_render.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index cdf8eff..2f3d950 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1038,6 +1038,16 @@ glamor_composite_choose_shader(CARD8 op,
}
#endif
+/* If the source and mask are two differently-formatted views of
+ * the same pixmap bits, and the pixmap was already uploaded (so
+ * the dynamic code above doesn't apply), then fall back to
+ * software. We should use texture views to fix this properly.
+ */
+if (source_pixmap && source_pixmap == mask_pixmap &&
+source->format != mask->format) {
+goto fail;
+}
+
/*Before enter the rendering stage, we need to fixup
* transformed source and mask, if the transform is not int translate. */
if (key.source != SHADER_SOURCE_SOLID
--
1.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
[PATCH] Add a command line argument for disabling indirect GLX.
The attack surface for indirect GLX is huge, and it's of no use to
most people (if you get an indirect GL context, you're better served
by a immediate X error than actually trying to use an indirect GL
context and finding out that it doesn't support doing anything you
want, slowly). This flag gives you a chance to disable indirect GLX
in environments where you just don't need it.
I put in both the '+' and '-' arguments right now, so that it's easy
to patch the value to change the default policy.
---
glx/glxcmds.c| 10 ++
include/opaque.h | 1 +
os/utils.c | 8
3 files changed, 19 insertions(+)
diff --git a/glx/glxcmds.c b/glx/glxcmds.c
index 187e426..ded7aca 100644
--- a/glx/glxcmds.c
+++ b/glx/glxcmds.c
@@ -232,6 +232,16 @@ DoCreateContext(__GLXclientState * cl, GLXContextID gcId,
LEGAL_NEW_RESOURCE(gcId, client);
+/* Only allow creating indirect GLX contexts if allowed by server
+ * command line. Indirect GLX is of limited use (since it's only
+ * GL 1.4), it's slower than direct contexts, and it's a massive
+ * attack surface for buffer overflow type errors.
+ */
+if (!enableIndirectGLX && !isDirect) {
+client->errorValue = isDirect;
+return BadMatch;
+}
+
/*
** Find the display list space that we want to share.
**
diff --git a/include/opaque.h b/include/opaque.h
index 6b8071c..a2c54aa 100644
--- a/include/opaque.h
+++ b/include/opaque.h
@@ -56,6 +56,7 @@ extern _X_EXPORT Bool explicit_display;
extern _X_EXPORT int defaultBackingStore;
extern _X_EXPORT Bool disableBackingStore;
extern _X_EXPORT Bool enableBackingStore;
+extern _X_EXPORT Bool enableIndirectGLX;
extern _X_EXPORT Bool PartialNetwork;
extern _X_EXPORT Bool RunFromSigStopParent;
diff --git a/os/utils.c b/os/utils.c
index 83d85cd..bc5e7df 100644
--- a/os/utils.c
+++ b/os/utils.c
@@ -194,6 +194,8 @@ Bool noGEExtension = FALSE;
Bool CoreDump;
+Bool enableIndirectGLX = TRUE;
+
#ifdef PANORAMIX
Bool PanoramiXExtensionDisabledHack = FALSE;
#endif
@@ -538,6 +540,8 @@ UseMsg(void)
ErrorF("-fn string default font name\n");
ErrorF("-fp string default font path\n");
ErrorF("-help prints message with these options\n");
+ErrorF("+iglx Allow creating indirect GLX contexts
(default)\n");
+ErrorF("-iglx Prohibit creating indirect GLX contexts\n");
ErrorF("-I ignore all remaining arguments\n");
#ifdef RLIMIT_DATA
ErrorF("-ld intlimit data space to N Kb\n");
@@ -784,6 +788,10 @@ ProcessCommandLine(int argc, char *argv[])
UseMsg();
exit(0);
}
+else if (strcmp(argv[i], "+iglx") == 0)
+enableIndirectGLX = TRUE;
+else if (strcmp(argv[i], "-iglx") == 0)
+enableIndirectGLX = FALSE;
else if ((skip = XkbProcessArguments(argc, argv, i)) != 0) {
if (skip > 0)
i += skip - 1;
--
1.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] fb: Fix origin of source picture in fbGlyphs
On 2014-04-21 18:20, Keith Packard wrote:
> Peter Harris writes:
>
>> If a source picture doesn't repeat and a mask format is specified, the
>> incorrect calulation of the origin of the glyphs caused the glyphs to
>> not be drawn at all.
>>
>> Noticed when running gtk-demo from RHEL 6.5 and selecting "Rotated
>> Text".
>
> Can you explain a bit more about how to reproduce this? I'm running the
> gtk+2.0 gtk-demo app from the gtk2.0-examples debian package and not
> seeing anything obviously incorrect?
RHEL is about the only distribution us Debian users can call "outdated"
with a straight face.
Recent gtk-demo uses a solid (or at least repeating) source picture. The
older gtk-demo used a non-repeating source picture with a width and
height equal to that of the rotated text. I think the older gtk-demo is
the only app I've ever seen in the wild that uses a non-repeating source
picture.
I just whipped up a minimal example; see attached. With miGlyphs (eg.
before 9cbcb5bd6a5360a128d15b77a02d8d3351f74366) it draws a green X in
the middle of the window. With fbGlyphs (before my patch), the window
stays blank.
Peter Harris
--
Open Text Connectivity Solutions Group
Peter Harrishttp://connectivity.opentext.com/
Research and DevelopmentPhone: +1 905 762 6001
phar...@opentext.comToll Free: 1 877 359 4866
#include
#include
#include
#include
#include
#include
// 16 x 16 pictfmt_a8 "glyph"
static const char glyph[] = {
0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff,
0, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0,
0, 0, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0, 0,
0, 0, 0, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0,
0, 0, 0, 0, 0xff, 0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0xff, 0, 0, 0, 0, 0xff, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0xff, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0xff, 0xff, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0xff, 0xff, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0xff, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0xff, 0, 0, 0, 0, 0xff, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0xff, 0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0, 0,
0, 0, 0, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0, 0, 0,
0, 0, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0, 0,
0, 0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff, 0,
0xff, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0xff,
};
#define GLYPH_SIZE 16
#define WIN_SIZE 200
static struct {
uint8_t len;
uint8_t pad[3];
uint16_t deltax, deltay;
uint8_t glyph;
uint8_t pad2[3];
} elt = { len:1, glyph:1, deltax:WIN_SIZE/2 - GLYPH_SIZE/2, deltay:WIN_SIZE/2 -
GLYPH_SIZE/2 };
int main(int argc, char *argv[])
{
int screen;
xcb_connection_t *c = xcb_connect(NULL, &screen);
if (!c || xcb_connection_has_error(c)) {
fprintf(stderr, "Cannot open default display \"%s\"\n",
getenv("DISPLAY"));
return EXIT_FAILURE;
}
// Find root window and depth
const xcb_setup_t *setup = xcb_get_setup(c);
if (screen >= setup->roots_len)
screen = 0;
xcb_screen_iterator_t si = xcb_setup_roots_iterator(setup);
for (int i=0; i < screen; i++)
xcb_screen_next(&si);
xcb_window_t root = si.data->root;
uint8_t depth = si.data->root_depth;
xcb_visualid_t visual = si.data->root_visual;
// Find picture formats
xcb_render_query_pict_formats_reply_t *qpf;
qpf = xcb_render_query_pict_formats_reply(c,
xcb_render_query_pict_formats(c), NULL);
if (!qpf) {
fprintf(stderr, "Cannot query RENDER picture formats\n");
return EXIT_FAILURE;
}
xcb_render_pictformat_t fmt_a8 = 0;
xcb_render_pictforminfo_iterator_t pfi =
xcb_render_query_pict_formats_formats_iterator(qpf);
for (int i = 0; i < xcb_render_query_pict_formats_formats_length(qpf); i++)
{
if (pfi.data->depth == 8 &&
pfi.data->type == XCB_RENDER_PICT_TYPE_DIRECT &&
pfi.data->direct.alpha_mask == 0xFF) {
fmt_a8 = pfi.data->id;
break;
}
xcb_render_pictforminfo_next(&pfi);
}
if (!fmt_a8) {
fprintf(stderr, "Cannot find a8 RENDER picture format\n");
return EXIT_FAILURE;
}
xcb_render_pictformat_t fmt_visual = 0;
xcb_render_pictscreen_iterator_t psi =
xcb_render_query_pict_formats_screens_iterator(qpf);
for (int i = 0; i < xcb_render_query_pict_formats_screens_length(qpf); i++)
{
xcb_render_pictdepth_iterator_t pdi =
xcb_render_pictscreen_depths_iterator(psi.data);
for (int j = 0; i < xcb_render_pictscreen_depths_length(psi.data); i++)
{
xcb_render_pictvisual_iterator_t pvi =
xcb_render_pictdepth_visuals_iterator(pdi.data);
for (int k = 0; k < xcb_render_pictdepth_visuals_length(pdi.data);
i++) {
if (pvi.data->visual == visual) {
fmt_visual = pvi.data->format;
Re: [PATCH 3/8] Drop duplicated extern definitions.
These first three look like they're already in http://cgit.freedesktop.org/xorg/app/rendercheck/commit/?id=2fd815135e7769aa9dd0d3b8cb558350ba7eb70d On 04/21/2014 11:56 AM, Eric Anholt wrote: --- main.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/main.c b/main.c index 9a97d72..241c03d 100644 --- a/main.c +++ b/main.c @@ -26,9 +26,6 @@ #include #include -extern int num_ops; -extern int num_colors; - Bool is_verbose = FALSE, minimalrendering = FALSE; int enabled_tests = ~0; /* Enable all tests by default */ ___ 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] fb: Fix origin of source picture in fbGlyphs
Peter Harris writes: > If a source picture doesn't repeat and a mask format is specified, the > incorrect calulation of the origin of the glyphs caused the glyphs to > not be drawn at all. > > Noticed when running gtk-demo from RHEL 6.5 and selecting "Rotated > Text". Can you explain a bit more about how to reproduce this? I'm running the gtk+2.0 gtk-demo app from the gtk2.0-examples debian package and not seeing anything obviously incorrect? -- keith.pack...@intel.com pgpGQ0p0wMY3e.pgp Description: PGP signature ___ 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] dmxConfigCanvasUpdate: Delay dereference until after checking for NULL
Flagged by cppcheck 1.64:
[hw/dmx/config/xdmxconfig.c:306] -> [hw/dmx/config/xdmxconfig.c:323]:
(warning) Possible null pointer dereference: fs - otherwise
it is redundant to check it against null.
Signed-off-by: Alan Coopersmith
---
hw/dmx/config/xdmxconfig.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/dmx/config/xdmxconfig.c b/hw/dmx/config/xdmxconfig.c
index 2b7b968..0540d01 100644
--- a/hw/dmx/config/xdmxconfig.c
+++ b/hw/dmx/config/xdmxconfig.c
@@ -303,7 +303,6 @@ dmxConfigCanvasUpdate(void)
fs = XQueryFont(dpy, gcontext);
for (pt = dmxConfigCurrent->subentry; pt; pt = pt->next) {
int x, y, len;
-int xo = 3, yo = fs->ascent + fs->descent + 2;
GC gc;
if (pt->type != dmxConfigDisplay)
@@ -321,6 +320,8 @@ dmxConfigCanvasUpdate(void)
y = dmxConfigWidgetHeight - 1;
XDrawRectangle(dpy, win, gc, x, y, w, h);
if (fs && len) {
+int xo = 3, yo = fs->ascent + fs->descent + 2;
+
while (len && XTextWidth(fs, pt->display->name, len) >= w - 2 * xo)
--len;
if (len)
--
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: [Resend: PATCH] dmxConfigCanvasUpdate: Delay dereference until after checking for NULL
On 04/21/14 01:18 PM, Keith Packard wrote: Alan Coopersmith writes: Flagged by cppcheck 1.64: [hw/dmx/config/xdmxconfig.c:306] -> [hw/dmx/config/xdmxconfig.c:323]: (warning) Possible null pointer dereference: fs - otherwise it is redundant to check it against null. Signed-off-by: Alan Coopersmith Something is screwy with this patch -- git says: Applying: dmxConfigCanvasUpdate: Delay dereference until after checking for NULL fatal: corrupt patch at line 16 Sorry, that's what I get for using thunderbird to resend from my mail folder - I'll redo with git send-email. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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] composite: Fix memory leak in compCopyWindow
Peter Harris writes: > Signed-off-by: Peter Harris Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpTN_JeEyC6X.pgp Description: PGP signature ___ 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] dixfonts: Turn a missing directory ErrorF into a DebugF
"Jasper St. Pierre" writes: > On systems without these directories, we don't need to be complaining > loudly. > > Reviewed-by: Kristian Hoegsberg Merged. ba5c2b6..ea15f8b master -> master -- keith.pack...@intel.com pgpxkijpPQhBg.pgp Description: PGP signature ___ 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: [PULL] Xwayland fixes
Kristian Høgsberg writes: > Kristian Høgsberg (4): > xwayland: Build without GLX extension > xwayland: Build without xshmfence > configure.ac: Remove check for WAYLAND_SCANNER_RULES > xwayland: Remove left-over ErrorF logging Merged. 9c86d5f..ba5c2b6 master -> master -- keith.pack...@intel.com pgp86agr75AT7.pgp Description: PGP signature ___ 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: Fix accelerated rendering of GTK's ARGB vs xBGR composites.
Eric Anholt writes: > +/* If the formats don't match, and the pixmap was already uploaded > + * (so the dynamic code above doesn't apply), then fall back to > + * software. We should use texture views to fix this properly. > + */ > +if (source_pixmap == mask_pixmap && source->format != mask->format) > +goto fail; source_pixmap is NULL for solid sources. mask_pixmap is NULL for solid masks or when mask is NULL. In the latter case, this crashes... From 7bf2affa6c3cad75e4eef939f74d508893d53803 Mon Sep 17 00:00:00 2001 From: Keith Packard Date: Mon, 21 Apr 2014 14:54:40 -0700 Subject: [PATCH] Only perform the mask comparison when both mask and source are pixmaps --- glamor/glamor_render.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index 56afc38..bed5161 100644 --- a/glamor/glamor_render.c +++ b/glamor/glamor_render.c @@ -1038,11 +1038,11 @@ glamor_composite_choose_shader(CARD8 op, } #endif -/* If the formats don't match, and the pixmap was already uploaded +/* If the formats don't match, and the pixmaps were already uploaded * (so the dynamic code above doesn't apply), then fall back to * software. We should use texture views to fix this properly. */ -if (source_pixmap == mask_pixmap && source->format != mask->format) +if (source_pixmap && source_pixmap == mask_pixmap && source->format != mask->format) goto fail; /*Before enter the rendering stage, we need to fixup -- 1.9.2 -- keith.pack...@intel.com pgpgDPXBSwEtn.pgp Description: PGP signature ___ 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: Handle unexpected GetGlyphs results better
Keith Packard writes: > GetGlyphs is supposed to always return the full list of characters > when there is a default character available. However, if an > application opens a 16-bit two dimensional font and then draws with > 8-bit requests, GetGlyphs will return zero glyphs if there is no 0th > row. This is probably a bug in GetGlyphs, but it's easy to protect > glamor from it by simply falling through to the case that handles > GetGlyphs failures for fonts without a default character. Eric asked why I was fixing this here instead of in GetGlyphs itself. The reason is that the underlying bug is in libXfont, and while the rest of the server has bugs because of that, they don't crash as a result. I've also sent a bug fix for libXfont that will make the rest of the backends work correctly for this case. -- keith.pack...@intel.com pgp2EQcrhhXFJ.pgp Description: PGP signature ___ 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/6] .gitignore: Add new autotools file 'test-driver'
Kristian Høgsberg writes: > Automake 1.12 introduces a new parallel test framework that uses a shell > script helper and generates *.log and *.trs files. Add to .gitignore. This one got lost in the rest of the Xwayland integration 28fa5dd..9c86d5f master -> master -- keith.pack...@intel.com pgpnJ2c9eLUS_.pgp Description: PGP signature ___ 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] Use default glyphs when getting 16-bit font with 8-bit text
When accessing a 16-bit font with firstRow > 0 with 8-bit text, check
to see if the font has a default character and return that for every
incoming character.
Signed-off-by: Keith Packard
---
src/bitmap/bitmap.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/bitmap/bitmap.c b/src/bitmap/bitmap.c
index 9b20faf..0a379eb 100644
--- a/src/bitmap/bitmap.c
+++ b/src/bitmap/bitmap.c
@@ -63,8 +63,12 @@ bitmapGetGlyphs(FontPtr pFont, unsigned long count, unsigned
char *chars,
case Linear8Bit:
case TwoD8Bit:
- if (pFont->info.firstRow > 0)
+ if (pFont->info.firstRow > 0) {
+if (pDefault)
+while (count--)
+*glyphs++ = pDefault;
break;
+}
if (pFont->info.allExist && pDefault) {
while (count--) {
c = (*chars++) - firstCol;
--
1.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
[PATCH] dixfonts: Turn a missing directory ErrorF into a DebugF
On systems without these directories, we don't need to be complaining
loudly.
Reviewed-by: Kristian Hoegsberg
---
dix/dixfonts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dix/dixfonts.c b/dix/dixfonts.c
index 83d2539..1c6442c 100644
--- a/dix/dixfonts.c
+++ b/dix/dixfonts.c
@@ -1658,7 +1658,7 @@ SetFontPathElements(int npaths, unsigned char *paths, int
*bad, Bool persist)
err = (*fpe_functions[fpe->type].init_fpe) (fpe);
if (err != Successful) {
if (persist) {
-ErrorF
+DebugF
("[dix] Could not init font path element %s,
removing from list!\n",
fpe->name);
}
--
1.9.0
___
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: [Resend: PATCH] dmxConfigCanvasUpdate: Delay dereference until after checking for NULL
Alan Coopersmith writes:
> Flagged by cppcheck 1.64:
> [hw/dmx/config/xdmxconfig.c:306] -> [hw/dmx/config/xdmxconfig.c:323]:
> (warning) Possible null pointer dereference: fs - otherwise
> it is redundant to check it against null.
>
> Signed-off-by: Alan Coopersmith
Something is screwy with this patch -- git says:
Applying: dmxConfigCanvasUpdate: Delay dereference until after checking for NULL
fatal: corrupt patch at line 16
> ---
> hw/dmx/config/xdmxconfig.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/dmx/config/xdmxconfig.c b/hw/dmx/config/xdmxconfig.c
> index 2b7b968..0540d01 100644
> --- a/hw/dmx/config/xdmxconfig.c
> +++ b/hw/dmx/config/xdmxconfig.c
> @@ -303,7 +303,6 @@ dmxConfigCanvasUpdate(void)
> fs = XQueryFont(dpy, gcontext);
> for (pt = dmxConfigCurrent->subentry; pt; pt = pt->next) {
> int x, y, len;
> -int xo = 3, yo = fs->ascent + fs->descent + 2;
> GC gc;
>if (pt->type != dmxConfigDisplay)
> @@ -321,6 +320,8 @@ dmxConfigCanvasUpdate(void)
> y = dmxConfigWidgetHeight - 1;
> XDrawRectangle(dpy, win, gc, x, y, w, h);
> if (fs && len) {
> +int xo = 3, yo = fs->ascent + fs->descent + 2;
> +
> while (len && XTextWidth(fs, pt->display->name, len) >= w - 2 *
> xo)
> --len;
> if (len)
> --
> 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
--
keith.pack...@intel.com
pgpijfxWbtucV.pgp
Description: PGP signature
___
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/2] configure: require fontsproto 2.1.3 for pointer typedef removal
Julien Cristau writes: > Signed-off-by: Julien Cristau Both of these are merged: 6d892ad..28fa5dd master -> master -- keith.pack...@intel.com pgpo6jcKOAySt.pgp Description: PGP signature ___ 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: glamor versus AIGLX GL context series
Michel Dänzer writes: > On 19.04.2014 03:39, Eric Anholt wrote: >> Here it is, at long last. I was stumped for several days with a weird >> fbo incomplete that was happening after my first round of fixes, and >> it took a day's detour of cooking up a Xephyr with DRI3 to get a fast >> debug environment and figure out what was going on (xephyr-glamor-egl >> is that branch. I warn you: that branch is almost entirely made up of >> layering violations and bad assumptions, and should not be viewed by >> people with a weak stomach). >> >> With this series, I've run piglit on my glamor-using desktop, and also >> played with some LIBGL_ALWAYS_INDIRECT=1 glxgears. Those both used to >> take down my server in different ways, so I think this fixes what we >> need for 1.16. However, swrast AIGLX (as used in xephyr-glamor-dri3) >> has a problem with recursive flushes during the loader's GetImage, and >> I don't have a solution to it. >> >> This branch can be found on glamor-gl-context-2 of my tree. > > This didn't reliably survive LIBGL_ALWAYS_INDIRECT=1 glxgears for me, let > alone piglit. valgrind found this: > > By changing the context, it may also invalidate the DRI2 buffer information, > so we need to get that again. > > Fixes crashes due to use-after-free with LIBGL_ALWAYS_INDIRECT=1 glxgears > and piglit. Glad to see things are working for you. I've added it to the series. If we can get this and the render change reviewed, I think the must-do items for glamor in 1.16 will be done. pgpvD01gcIKzH.pgp Description: PGP signature ___ 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 3/8] Drop duplicated extern definitions.
--- main.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/main.c b/main.c index 9a97d72..241c03d 100644 --- a/main.c +++ b/main.c @@ -26,9 +26,6 @@ #include #include -extern int num_ops; -extern int num_colors; - Bool is_verbose = FALSE, minimalrendering = FALSE; int enabled_tests = ~0;/* Enable all tests by default */ -- 1.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
rendercheck: warnings cleanups and a new test
keithp sent me some code for a new test that reproduced a bug he was experiencing in glamor, so I pulled out rendercheck to add the testcase to it and found that it was really verbose with all the new warnings. The new warnings didn't appear to reveal actual bugs, though. ___ 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 2/8] Drop a duplicated prototype.
--- rendercheck.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/rendercheck.h b/rendercheck.h index 34d06c5..6cae450 100644 --- a/rendercheck.h +++ b/rendercheck.h @@ -194,9 +194,6 @@ trans_srccoords_test_2(Display *dpy, picture_info *win, picture_info *white, Bool render_to_gradient_test(Display *dpy, picture_info *src); -Bool linear_gradient_test(Display *dpy, picture_info *win, - picture_info *dst, int op, picture_info *dst_color); - Bool repeat_test(Display *dpy, picture_info *win, picture_info *dst, int op, picture_info *dst_color, picture_info *c1, picture_info *c2, -- 1.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
[PATCH 7/8] Shut up some const assignment warnings.
Trying to make all the callchain related to these const is too hard, and it's
not like marking things const helps either the developer or the compiler.
---
t_repeat.c | 2 +-
t_srccoords.c | 2 +-
t_tsrccoords.c | 2 +-
t_tsrccoords2.c | 2 +-
tests.c | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t_repeat.c b/t_repeat.c
index 4e26136..560d581 100644
--- a/t_repeat.c
+++ b/t_repeat.c
@@ -73,7 +73,7 @@ repeat_test(Display *dpy, picture_info *win, picture_info
*dst, int op,
src.format = XRenderFindStandardFormat(dpy, PictStandardARGB32);
src.pict = XRenderCreatePicture(dpy, src.d, src.format,
CPComponentAlpha | CPRepeat, &pa);
- src.name = "repeat picture";
+ src.name = (char *)"repeat picture";
/* Fill to the first color */
XRenderComposite(dpy, PictOpSrc, c1->pict, None, src.pict,
diff --git a/t_srccoords.c b/t_srccoords.c
index 6aff6d5..3f23b95 100644
--- a/t_srccoords.c
+++ b/t_srccoords.c
@@ -46,7 +46,7 @@ static picture_info *create_target_picture(Display *dpy)
p->d = XCreatePixmap(dpy, RootWindow(dpy, 0), 5, 5, 32);
p->format = XRenderFindStandardFormat(dpy, PictStandardARGB32);
p->pict = XRenderCreatePicture(dpy, p->d, p->format, 0, NULL);
- p->name = "target picture";
+ p->name = (char *)"target picture";
for (i = 0; i < 25; i++) {
int x = i % 5;
diff --git a/t_tsrccoords.c b/t_tsrccoords.c
index 124fdc9..1f78fb0 100644
--- a/t_tsrccoords.c
+++ b/t_tsrccoords.c
@@ -46,7 +46,7 @@ static picture_info *create_dot_picture(Display *dpy)
p->d = XCreatePixmap(dpy, RootWindow(dpy, 0), 5, 5, 32);
p->format = XRenderFindStandardFormat(dpy, PictStandardARGB32);
p->pict = XRenderCreatePicture(dpy, p->d, p->format, 0, NULL);
- p->name = "dot picture";
+ p->name = (char *)"dot picture";
for (i = 0; i < 25; i++) {
int x = i % 5;
diff --git a/t_tsrccoords2.c b/t_tsrccoords2.c
index 4449dca..123f936 100644
--- a/t_tsrccoords2.c
+++ b/t_tsrccoords2.c
@@ -46,7 +46,7 @@ static picture_info *create_target_picture(Display *dpy)
p->d = XCreatePixmap(dpy, RootWindow(dpy, 0), 5, 5, 32);
p->format = XRenderFindStandardFormat(dpy, PictStandardARGB32);
p->pict = XRenderCreatePicture(dpy, p->d, p->format, 0, NULL);
- p->name = "target picture";
+ p->name = (char *)"target picture";
for (i = 0; i < 25; i++) {
int x = i % 5;
diff --git a/tests.c b/tests.c
index 4dacb5b..d59b938 100644
--- a/tests.c
+++ b/tests.c
@@ -405,7 +405,7 @@ do_tests(Display *dpy, picture_info *win)
picture_3x3.format = XRenderFindStandardFormat(dpy, PictStandardARGB32);
picture_3x3.pict = XRenderCreatePicture(dpy, picture_3x3.d,
picture_3x3.format, 0, NULL);
- picture_3x3.name = "3x3 sample picture";
+ picture_3x3.name = (char *)"3x3 sample picture";
for (i = 0; i < 9; i++) {
int x = i % 3;
int y = i / 3;
@@ -424,7 +424,7 @@ do_tests(Display *dpy, picture_info *win)
c.blue = (int)(colors[i].b*65535);
pictures_solid[i].pict = XRenderCreateSolidFill(dpy, &c);
pictures_solid[i].format = format_list[argb32index];
-pictures_solid[i].name = "Solid";
+pictures_solid[i].name = (char *)"Solid";
}
#define RECORD_RESULTS() \
--
1.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
[PATCH 8/8] Add test for GTK rendering bug in glamor.
Signed-off-by: Eric Anholt
---
COPYING | 19 +++
Makefile.am | 1 +
main.c| 2 +
rendercheck.h | 4 ++
t_gtk_argb_xbgr.c | 150 ++
tests.c | 10
6 files changed, 186 insertions(+)
create mode 100644 t_gtk_argb_xbgr.c
diff --git a/COPYING b/COPYING
index af1d06b..efe8756 100644
--- a/COPYING
+++ b/COPYING
@@ -1,3 +1,22 @@
+Rendercheck is a combination of GPLv2-or-later and MIT-licensed code.
+
+/* Copyright © 2014 Keith Packard
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
Copyright 2004 Eric Anholt
Permission to use, copy, modify, distribute, and sell this software and its
diff --git a/Makefile.am b/Makefile.am
index 9afbed5..36d38e4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -13,6 +13,7 @@ rendercheck_SOURCES = \
t_dstcoords.c \
t_fill.c \
t_gradient.c \
+ t_gtk_argb_xbgr.c \
t_repeat.c \
t_srccoords.c \
t_tsrccoords.c \
diff --git a/main.c b/main.c
index 853cc12..78b42fd 100644
--- a/main.c
+++ b/main.c
@@ -223,6 +223,8 @@ int main(int argc, char **argv)
enabled_tests |= TEST_TRIANGLES;
} else if (strcmp(test, "bug7366") == 0) {
enabled_tests |= TEST_BUG7366;
+ } else if (strcmp(test, "gtk_argb_xbgr") == 0) {
+ enabled_tests |= TEST_GTK_ARGB_XBGR;
} else {
usage(argv[0]);
}
diff --git a/rendercheck.h b/rendercheck.h
index ad30dd6..125a929 100644
--- a/rendercheck.h
+++ b/rendercheck.h
@@ -81,6 +81,7 @@ struct op_info {
#define TEST_REPEAT0x0400
#define TEST_TRIANGLES 0x0800
#define TEST_BUG7366 0x1000
+#define TEST_GTK_ARGB_XBGR 0x2000
extern int pixmap_move_iter;
extern int win_width, win_height;
@@ -217,3 +218,6 @@ trifan_test(Display *dpy, picture_info *win, picture_info
*dst, int op,
Bool
bug7366_test(Display *dpy);
+
+Bool
+gtk_argb_xbgr_test(Display *dpy);
diff --git a/t_gtk_argb_xbgr.c b/t_gtk_argb_xbgr.c
new file mode 100644
index 000..b80e58b
--- /dev/null
+++ b/t_gtk_argb_xbgr.c
@@ -0,0 +1,150 @@
+/* Copyright © 2014 Keith Packard
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+/* Test Render's ability to flip bytes around when the source and mask are the
+ * same pixmap.
+ */
+
+#include
+#include
+#include
+#include
+#include "rendercheck.h"
+
+#define WIDTH 1
+#define HEIGHT 1
+
+#define PIXEL_ABGR 0xff886644
+#define PIXEL_RGB 0x446688
+
+Bool
+gtk_argb_xbgr_test(Display *dpy)
+{
+ int x, y;
+ Pixmap pix_32;
+ Pixmap pix_24;
+ Picture pic_24;
+ Picture pic_32_xbgr;
+ Picture pic_32_argb;
+ XRenderPictFormat templ;
+ XRenderPictFormat *pic_xbgr_format;
+ XRenderPictFormat *pic_argb_format;
+ XRenderPictFormat *pic_rgb_format;
+ GC gc_32;
+ XImage *image_24, *image_32;
+
+ templ.type = PictTypeDirect;
+ templ.depth = 32;
+ templ.direct.alphaMask = 0;
+ templ.direct.red = 0;
+ templ.direct.green = 8;
+ templ.direct.blue = 16;
+
+ pic_xbgr_format = XRenderFindFormat(dpy,
+ PictFormatType |
+ PictFormatDepth |
+ PictFormatAlphaMask |
+ PictFormatRed |
+ PictFormatGreen |
+ PictFormatBlue,
+ &templ, 0);
+
+
[PATCH 5/8] Convert to using asprintf for describe_format.
This simplifies the manual strcatting mess and avoids potential overflow
issues.
---
Makefile.am | 1 +
main.c| 23 ---
rendercheck.h | 2 +-
t_blend.c | 6 --
t_fill.c | 7 ---
tests.c | 27 +++
6 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index b19ae4a..9afbed5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -20,6 +20,7 @@ rendercheck_SOURCES = \
t_triangles.c
AM_CFLAGS = $(RC_CFLAGS) $(CWARNFLAGS)
+AM_CPPFLAGS = -D_GNU_SOURCE
rendercheck_LDADD = $(RC_LIBS)
MAINTAINERCLEANFILES = ChangeLog INSTALL
diff --git a/main.c b/main.c
index 241c03d..853cc12 100644
--- a/main.c
+++ b/main.c
@@ -54,12 +54,15 @@ bit_count(int i)
/* This is not complete, but decent enough for now.*/
void
-describe_format(char *desc, int len, XRenderPictFormat *format)
+describe_format(char **desc, const char *prefix, XRenderPictFormat *format)
{
char ad[4] = "", rd[4] = "", gd[4] = "", bd[4] = "";
int ac, rc, gc, bc;
int ashift;
+ if (!prefix)
+ prefix = "";
+
ac = bit_count(format->direct.alphaMask);
rc = bit_count(format->direct.redMask);
gc = bit_count(format->direct.greenMask);
@@ -89,14 +92,14 @@ describe_format(char *desc, int len, XRenderPictFormat
*format)
if (ashift > format->direct.red) {
if (format->direct.red > format->direct.blue)
- snprintf(desc, len, "%s%s%s%s", ad, rd, gd, bd);
+ asprintf(desc, "%s%s%s%s%s", prefix, ad, rd, gd, bd);
else
- snprintf(desc, len, "%s%s%s%s", ad, bd, gd, rd);
+ asprintf(desc, "%s%s%s%s%s", prefix, ad, bd, gd, rd);
} else {
if (format->direct.red > format->direct.blue)
- snprintf(desc, len, "%s%s%s%s", rd, gd, bd, ad);
+ asprintf(desc, "%s%s%s%s%s", prefix, rd, gd, bd, ad);
else
- snprintf(desc, len, "%s%s%s%s", bd, gd, rd, ad);
+ asprintf(desc, "%s%s%s%s%s", prefix, bd, gd, rd, ad);
}
}
@@ -277,12 +280,10 @@ int main(int argc, char **argv)
window.format = XRenderFindVisualFormat(dpy, a.visual);
window.pict = XRenderCreatePicture(dpy, window.d,
window.format, 0, NULL);
- window.name = (char *)malloc(20);
- if (window.name == NULL)
- errx(1, "malloc error");
- describe_format(window.name, 20, window.format);
- printf("Window format: %s\n", window.name);
- strncat(window.name, " window", 20);
+ describe_format(&format, NULL, window.format);
+ printf("Window format: %s\n", format);
+ asprintf(&window.name, "%s window", format);
+ free(format);
XSelectInput(dpy, window.d, ExposureMask);
XMapWindow(dpy, window.d);
diff --git a/rendercheck.h b/rendercheck.h
index 7da59a5..ad30dd6 100644
--- a/rendercheck.h
+++ b/rendercheck.h
@@ -96,7 +96,7 @@ extern int num_colors;
/* main.c */
void
-describe_format(char *desc, int len, XRenderPictFormat *format);
+describe_format(char **desc, const char *prefix, XRenderPictFormat *format);
int
bit_count(int i);
diff --git a/t_blend.c b/t_blend.c
index 57b2f2d..b436fe4 100644
--- a/t_blend.c
+++ b/t_blend.c
@@ -21,6 +21,7 @@
*/
#include
+#include
#include "rendercheck.h"
@@ -109,10 +110,10 @@ blend_test(Display *dpy, picture_info *win, picture_info
*dst,
color_correct(dst, &expected);
if (eval_diff(&acc, &expected,
&tested) > 3.) {
- char srcformat[20];
+ char *srcformat;
snprintf(testname, 20, "%s
blend", ops[op[i]].name);
- describe_format(srcformat,
20, src_color[j]->format);
+ describe_format(&srcformat,
NULL, src_color[j]->format);
print_fail(testname,
&expected, &tested, 0, 0,
eval_diff(&acc,
&expected, &tested));
printf("src color: %.2f
%.2f %.2f %.2f (%s)\n"
@@ -125,6 +126,7 @@ blend_test(Display *dpy, picture_info *win, picture_info
*dst,
dst_color[k]->color.b,
dst_color[k]->color.a);
printf("src: %s, dst:
%s\n", src_color[j]->name, dst->name);
+ free(srcformat);
return
[PATCH 4/8] Fix const cast warnings in our ops definitions.
We only store string literals here.
---
rendercheck.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rendercheck.h b/rendercheck.h
index 6cae450..7da59a5 100644
--- a/rendercheck.h
+++ b/rendercheck.h
@@ -64,7 +64,7 @@ typedef struct _picture_info {
struct op_info {
int op;
- char *name;
+ const char *name;
Bool disabled;
};
--
1.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
[PATCH 6/8] Disable useless shadow warnings.
They never find real bugs in my experience. --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index 4fa5a63..4ec7a8f 100644 --- a/configure.ac +++ b/configure.ac @@ -17,6 +17,7 @@ m4_ifndef([XORG_MACROS_VERSION], [m4_fatal([must install xorg-macros 1.8 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.8) XORG_DEFAULT_OPTIONS +CWARNFLAGS=`echo $CWARNFLAGS | sed 's|-Wshadow||g'` # Checks for header files. AC_CHECK_HEADERS([err.h]) -- 1.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
[PATCH 1/8] rendercheck: Fix compiler dead code warning.
This was apparently copy and pasted from the 1x1 repeat code above.
---
tests.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests.c b/tests.c
index f722bc6..e2ae645 100644
--- a/tests.c
+++ b/tests.c
@@ -390,14 +390,12 @@ do_tests(Display *dpy, picture_info *win)
errx(1, "malloc error");
for (i = 0; i < num_colors * nformats; i++) {
- XRenderPictureAttributes pa;
color4d *c = &colors[i / nformats];
/* The standard PictFormat numbers go from 0 to 4 */
pictures_10x10[i].format = format_list[i % nformats];
pictures_10x10[i].d = XCreatePixmap(dpy, RootWindow(dpy, 0), 10,
10, pictures_10x10[i].format->depth);
- pa.repeat = TRUE;
pictures_10x10[i].pict = XRenderCreatePicture(dpy,
pictures_10x10[i].d, pictures_10x10[i].format, 0, NULL);
--
1.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
[PULL] Xwayland fixes
The following changes since commit c7011249d2abe6cc7af82ee4b79d8f6873444707: xkb: Verify reads of compiled keymap header and TOC (2014-04-18 16:30:18 -0700) are available in the git repository at: ssh://people.freedesktop.org/~krh/xserver xwayland-for-keithp for you to fetch changes up to 66b602474047c499b8a888267a489790fc9f9d85: xwayland: Remove left-over ErrorF logging (2014-04-21 11:25:12 -0700) Kristian Høgsberg (4): xwayland: Build without GLX extension xwayland: Build without xshmfence configure.ac: Remove check for WAYLAND_SCANNER_RULES xwayland: Remove left-over ErrorF logging configure.ac | 1 - hw/xwayland/xwayland.c | 10 +++--- 2 files changed, 7 insertions(+), 4 deletions(-) ___ 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/3] randr: Fix crash for NULL swap dispatch procs
Alan Coopersmith writes: > On 04/18/14 06:29 PM, Robert Morell wrote: >> The previous code was checking the wrong table for function pointers. >> >> Signed-off-by: Robert Morell > > For the series (1-3), > Reviewed-by: Alan Coopersmith Merged. 138bf5a..6d892ad master -> master -- keith.pack...@intel.com pgpg9rCtLd36e.pgp Description: PGP signature ___ 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 0/2] Fix uninitialized reply in DRI2SwapBuffers
Jamey Sharp writes: > These two patches together clean up commit b180e439, which has been in > xserver releases since 1.9. That commit was attempting to fix an > OML_sync_control spec compliance bug; these finish the job. > > I'd like to suggest that, once these patches are merged to master, they > also be included in any future stable point releases. Merged. c701124..138bf5a master -> master -- keith.pack...@intel.com pgpo3WFwN7_Ex.pgp Description: PGP signature ___ 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] xwayland: Fix damage reporting
Why do we end up with such a large damage anyway? Technically, we need to
ignore this in mutter, as it's perfectly valid to have a too-big damage.
Rather than do the clip in Xwayland, I'd like to figure out why damage
reporting for a window we know the bounds of is so unrealistically large,
because this could be a bug hitting us on Xorg as well.
On Sat, Apr 19, 2014 at 4:26 AM, Adel Gadllah wrote:
> Currently we accumulate damage in a list and call wl_surface_damage() for
> every
> rectangle in the accumulated regions in xwl_screen_post_damage(). If the
> window
> size changes we might end up with a damage region that exceeds the window
> bounds causing compositors like mutter to call glTexSubImage2D with an area
> that exceeds the buffer dimensions causing GL_INVALID_VALUE.
>
> So intersect the damage region with the window's shape region in
> xwl_screen_post_damage().
>
> Signed-off-by: Adel Gadllah
> ---
> hw/xwayland/xwayland.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index c2c6481..7f810aa 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -325,7 +325,7 @@ static void
> xwl_screen_post_damage(struct xwl_screen *xwl_screen)
> {
> struct xwl_window *xwl_window;
> -RegionPtr region;
> +RegionPtr region, shape_region;
> BoxPtr box;
> int count, i;
> struct wl_buffer *buffer;
> @@ -334,6 +334,9 @@ xwl_screen_post_damage(struct xwl_screen *xwl_screen)
> xorg_list_for_each_entry(xwl_window, &xwl_screen->damage_window_list,
> link_damage) {
> region = DamageRegion(xwl_window->damage);
> +shape_region = wBoundingShape(xwl_window->window);
> +if (shape_region)
> +RegionIntersect(region, region, shape_region);
> count = RegionNumRects(region);
>
> pixmap = (*xwl_screen->screen->GetWindowPixmap)
> (xwl_window->window);
> --
> 1.9.0
>
>
--
Jasper
___
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: Fix accelerated rendering of GTK's ARGB vs xBGR composites.
There is some complicated code to support tweaking the format as we upload from a SHM pixmap (aka the GTK icon cache), but if we weren't sourcing from a SHM pixmap we just forgot to check that the formats matched at all. We could potentially be a little more discerning here (xRGB source and ARGB mask would be fine, for example), but this will all change with texture views anyway, so just get the rendering working for 1.16 release. Fixes the new rendercheck gtk_argb_xbgr test. --- glamor/glamor_render.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index cdf8eff..56afc38 100644 --- a/glamor/glamor_render.c +++ b/glamor/glamor_render.c @@ -1038,6 +1038,13 @@ glamor_composite_choose_shader(CARD8 op, } #endif +/* If the formats don't match, and the pixmap was already uploaded + * (so the dynamic code above doesn't apply), then fall back to + * software. We should use texture views to fix this properly. + */ +if (source_pixmap == mask_pixmap && source->format != mask->format) +goto fail; + /*Before enter the rendering stage, we need to fixup * transformed source and mask, if the transform is not int translate. */ if (key.source != SHADER_SOURCE_SOLID -- 1.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: bug in glamor on ShmPutImage for XY images
Jamey Sharp writes: > I haven't understood enough of the implementation to see how to fix > this, but I can reliably crash Xephyr this way: > > hw/kdrive/ephyr/Xephyr :1 -screen 1024x768 -glamor > DISPLAY=:1 x11perf -shmputxy10 > > Without the -glamor option to Xephyr, the x11perf command runs > successfully. I'm testing on current git master. > > As far as I can tell, fbPutXYImage is getting called with a pDrawable > for which the pixmap's devPrivate.ptr is NULL. It's setting FbBits > *dst to that NULL and passing it down to fbBltOne, which then > segfaults. I ran into this segfault yesterday, and decided to just pull keithp's rewrite of get/putimage: It's massively faster, and it also fixes this bug. pgpu_C1qBD_a0.pgp Description: PGP signature ___ 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] Make glamor build with --enable-debug.
Jamey Sharp writes: > Bad anholt, no biscuit. Broken in commit > 4c9a20072552c52b3763bd73e7a7e9b9cb8b4993. Applied this to my -fixes tree, which I expect to send pull-request for today. pgpKeoY_SrHjF.pgp Description: PGP signature ___ 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-1.4 v2] Require fontsproto < 2.1.3 for matching function prototypes
Looks good. Reviewed-By: Thomas Klausner On Mon, Apr 21, 2014 at 07:31:59AM -0700, Alan Coopersmith wrote: > Building libXfont-1.4.x against fontsproto 2.1.3 causes clang > complaints of: > > patcache.c:130:1: error: conflicting types for 'CacheFontPattern' > CacheFontPattern (FontPatternCachePtr cache, > ^ > patcache.c:176:1: error: conflicting types for 'FindCachedFontPattern' > FindCachedFontPattern (FontPatternCachePtr cache, > ^ > > due to the constification of arguments not matching. > > Signed-off-by: Alan Coopersmith > --- > > Oops, sent wrong patch before. > > configure.ac |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index cbb540a..4979c04 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -180,7 +180,7 @@ fi > AC_CHECK_LIB(m, hypot, [MATH_LIBS=-lm > AC_SUBST(MATH_LIBS)], AC_MSG_ERROR([*** libm is required])) > > -PKG_CHECK_MODULES(XFONT, xproto xtrans fontsproto fontenc) > +PKG_CHECK_MODULES(XFONT, [xproto xtrans fontsproto < 2.1.3 fontenc]) > > # Transport selection macro from xtrans.m4 > XTRANS_CONNECTION_FLAGS > -- > 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 > ___ 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-1.4 v2] Require fontsproto < 2.1.3 for matching function prototypes
Building libXfont-1.4.x against fontsproto 2.1.3 causes clang complaints of: patcache.c:130:1: error: conflicting types for 'CacheFontPattern' CacheFontPattern (FontPatternCachePtr cache, ^ patcache.c:176:1: error: conflicting types for 'FindCachedFontPattern' FindCachedFontPattern (FontPatternCachePtr cache, ^ due to the constification of arguments not matching. Signed-off-by: Alan Coopersmith --- Oops, sent wrong patch before. configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index cbb540a..4979c04 100644 --- a/configure.ac +++ b/configure.ac @@ -180,7 +180,7 @@ fi AC_CHECK_LIB(m, hypot, [MATH_LIBS=-lm AC_SUBST(MATH_LIBS)], AC_MSG_ERROR([*** libm is required])) -PKG_CHECK_MODULES(XFONT, xproto xtrans fontsproto fontenc) +PKG_CHECK_MODULES(XFONT, [xproto xtrans fontsproto < 2.1.3 fontenc]) # Transport selection macro from xtrans.m4 XTRANS_CONNECTION_FLAGS -- 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: glamor versus AIGLX GL context series
On 19.04.2014 03:39, Eric Anholt wrote:
> Here it is, at long last. I was stumped for several days with a weird
> fbo incomplete that was happening after my first round of fixes, and
> it took a day's detour of cooking up a Xephyr with DRI3 to get a fast
> debug environment and figure out what was going on (xephyr-glamor-egl
> is that branch. I warn you: that branch is almost entirely made up of
> layering violations and bad assumptions, and should not be viewed by
> people with a weak stomach).
>
> With this series, I've run piglit on my glamor-using desktop, and also
> played with some LIBGL_ALWAYS_INDIRECT=1 glxgears. Those both used to
> take down my server in different ways, so I think this fixes what we
> need for 1.16. However, swrast AIGLX (as used in xephyr-glamor-dri3)
> has a problem with recursive flushes during the loader's GetImage, and
> I don't have a solution to it.
>
> This branch can be found on glamor-gl-context-2 of my tree.
This didn't reliably survive LIBGL_ALWAYS_INDIRECT=1 glxgears for me, let
alone piglit. valgrind found this:
==32448== Invalid read of size 8
==32448==at 0x836EAB4: dri2GetBuffersWithFormat (glxdri2.c:746)
==32448==by 0xB808C8C: dri2_allocate_textures (dri2.c:185)
==32448==by 0xB806A94: dri_st_framebuffer_validate (dri_drawable.c:83)
==32448==by 0xB99DB09: st_framebuffer_validate (st_manager.c:193)
==32448==by 0xB99ECC0: st_api_make_current (st_manager.c:763)
==32448==by 0xB805D5C: dri_make_current (dri_context.c:253)
==32448==by 0xB7DCD54: driBindContext (dri_util.c:543)
==32448==by 0x8361217: DoMakeCurrent (glxcmds.c:639)
==32448==by 0x8365C0E: __glXDispatch (glxext.c:595)
==32448==by 0x4378F5: Dispatch (dispatch.c:432)
==32448==by 0x43BB0A: dix_main (main.c:296)
==32448==by 0x6A74B44: (below main) (libc-start.c:287)
==32448== Address 0xf6d5480 is 0 bytes inside a block of size 16 free'd
==32448==at 0x4C2870C: free (vg_replace_malloc.c:468)
==32448==by 0x563063: do_get_buffers (dri2.c:509)
==32448==by 0x5632C3: DRI2GetBuffersWithFormat (dri2.c:673)
==32448==by 0x836EA59: dri2GetBuffersWithFormat (glxdri2.c:724)
==32448==by 0xB808C8C: dri2_allocate_textures (dri2.c:185)
==32448==by 0xB806A94: dri_st_framebuffer_validate (dri_drawable.c:83)
==32448==by 0xB99DB09: st_framebuffer_validate (st_manager.c:193)
==32448==by 0xB99ECC0: st_api_make_current (st_manager.c:763)
==32448==by 0xB805D5C: dri_make_current (dri_context.c:253)
==32448==by 0xB7DCD54: driBindContext (dri_util.c:543)
==32448==by 0x836EA76: dri2GetBuffersWithFormat (glxdri2.c:729)
==32448==by 0xB808C8C: dri2_allocate_textures (dri2.c:185)
==32448==
The patch below fixes this.
From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
Date: Mon, 21 Apr 2014 17:40:47 +0900
Subject: [PATCH] glx: If DRI2GetBuffers(WithFormat) changes the GL context,
call it again
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
By changing the context, it may also invalidate the DRI2 buffer information,
so we need to get that again.
Fixes crashes due to use-after-free with LIBGL_ALWAYS_INDIRECT=1 glxgears
and piglit.
Signed-off-by: Michel Dänzer
---
glx/glxdri2.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/glx/glxdri2.c b/glx/glxdri2.c
index 7b368d2..c756bf5 100644
--- a/glx/glxdri2.c
+++ b/glx/glxdri2.c
@@ -676,6 +676,13 @@ dri2GetBuffers(__DRIdrawable * driDrawable,
if (cx != lastGLContext) {
lastGLContext = cx;
cx->makeCurrent(cx);
+
+/* If DRI2GetBuffers() changed the GL context, it may also have
+ * invalidated the DRI2 buffers, so let's get them again
+ */
+buffers = DRI2GetBuffers(private->base.pDraw,
+ width, height, attachments, count, out_count);
+assert(lastGLContext == cx);
}
if (*out_count > MAX_DRAWABLE_BUFFERS) {
@@ -727,6 +734,14 @@ dri2GetBuffersWithFormat(__DRIdrawable * driDrawable,
if (cx != lastGLContext) {
lastGLContext = cx;
cx->makeCurrent(cx);
+
+/* If DRI2GetBuffersWithFormat() changed the GL context, it may also
have
+ * invalidated the DRI2 buffers, so let's get them again
+ */
+buffers = DRI2GetBuffersWithFormat(private->base.pDraw,
+ width, height, attachments, count,
+ out_count);
+assert(lastGLContext == cx);
}
if (*out_count > MAX_DRAWABLE_BUFFERS) {
--
1.9.2
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:libXfont 2/2] Require fontsproto 2.1.3 for matching function prototypes
For the series: Reviewed-by: Thomas Klausner Thomas On Sun, Apr 20, 2014 at 06:23:40PM -0700, Alan Coopersmith wrote: > Building current libXfont git against fontsproto 2.1.2 causes clang > complaints of: > > patcache.c:130:1: error: conflicting types for 'CacheFontPattern' > CacheFontPattern (FontPatternCachePtr cache, > ^ > patcache.c:176:1: error: conflicting types for 'FindCachedFontPattern' > FindCachedFontPattern (FontPatternCachePtr cache, > ^ > > due to the constification of arguments not matching. > > Signed-off-by: Alan Coopersmith > --- > configure.ac |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configure.ac b/configure.ac > index cbb540a..e78e56a 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -180,7 +180,7 @@ fi > AC_CHECK_LIB(m, hypot, [MATH_LIBS=-lm > AC_SUBST(MATH_LIBS)], AC_MSG_ERROR([*** libm is required])) > > -PKG_CHECK_MODULES(XFONT, xproto xtrans fontsproto fontenc) > +PKG_CHECK_MODULES(XFONT, [xproto xtrans fontsproto >= 2.1.3 fontenc]) > > # Transport selection macro from xtrans.m4 > XTRANS_CONNECTION_FLAGS > -- > 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 > ___ 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
