[ANNOUNCE] xorg-server 1.12.1.902 (1.12.2 RC2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == Description == This is the second release candidate for 1.12.2. The primary changes from the first release candidate pertain to logging, build failures, and xinput. == Known Issues == Top Issues (1.12 Tracker, https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12) * #23938: [from 1.6.x] keys occasionally get stuck * #31501: [from 1.8.x] crash accessing font info with xfs in fontpath * #39094: WaitFor does not handle EIO (causes 100% cpu load) * #39838: Server crash in RENDER * #39949: [from 1.9.x] RandR panning & scaling don't work * #41124: [from 1.9.x] Another crash in GLX/DRI2 when resizing a window * #41149: Server crash pressing multimedia keys * patch on xorg-devel * #41653: Server crash in rotate * patch pending PULL to master * #43988: Use-after-free * patch in bug needs updated formatting & review * #44038: GL regression with wine Other Issues (1.13 Tracker, https://bugs.freedesktop.org/show_bug.cgi?id=44202) * #11053: Buffer overflow in fbCopyArea() * Has a patch, ajax thinks the patch is wrong * #17013: Issues when mising Xinerama and XCopyArea/Xdamage * Partial patch is available... still waiting on complete fix * #24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) * XKB weirdness. This looks diagnosed, so let's get a patch tested. * #27804: Enter/Leave event woes with multiple master devices * #29251: [from 1.8.x] server crash destroying GLX pixmaps * #32765: [from 1.8.x] Xephyr segfaults on 24bpp hosts * A possible fix is discussed, but Keith didn't like it. * #42219: Some override-redirect windows aren't getting rendered * #43434: Rotate causes loss of gamma changes * #47510: Xephyr memory leak == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server112Branch == Changes since 1.12.1.901 == Chase Douglas (2): Report logical button state in ProcXIQueryPointer Report touch emulated buttons in XIQueryPointer for XI 2.1 and earlier Daniel Kurtz (5): dix: don't BUG_WARN for button events from button-only device os/log: trivial cleanups os/xprintf: add Xvscnprintf and Xscnprintf os/log: only write timestamp if a message is actually written to logfile os/log: refactor logging Jeremy Huddleston (2): Revert "dix: when disabling a device, release all buttons and keys" configure.ac: Version bump to 1.12.1.902 (1.12.2 RC2) Keith Packard (2): hw/xfree86: Spurious ');' in xf86vmode.c messed up indentation badly hw/xfree86: Re-indent xf86vmode.c Michal Suchanek (1): dmx: Annotate dmxlog.c with _X_ATTRIBUTE_PRINTF and _X_NORETURN Peter Hutterer (1): dix: indentation fix git tag: xorg-server-1.12.1.902 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.1.902.tar.bz2 MD5: 29c8ccc0097daa31500b250b6b7cf31d xorg-server-1.12.1.902.tar.bz2 SHA1: f5ab539ac875551ba3ea8f29150bc1794b58 xorg-server-1.12.1.902.tar.bz2 SHA256: 052efb01c47348b4138c89ad5654be022a4d952acc6129b2ad2659bc1ff4d509 xorg-server-1.12.1.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.12.1.902.tar.gz MD5: 40b0de8c8fad46357ba2bf5b1bc18377 xorg-server-1.12.1.902.tar.gz SHA1: c5fc232decc3eaa18283ffb313dde8b0b73e48b3 xorg-server-1.12.1.902.tar.gz SHA256: aabeaf68ef7885ad2bc33a4a6ac2abb3c5c12ee563b53744932093a15a17d499 xorg-server-1.12.1.902.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iD8DBQFPuH90jC1Anjf1NmMRAgLcAJ4qzrDEVouUpLru3+rQ08U8bXWXugCdGExX +NYxg2MO/a4lQdsdEyHbSzA= =40vQ -END PGP SIGNATURE- ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XSetBackgroundPixmap question
Glynn Clements writes: > That seems to imply that the X server makes a copy of the pixmap data > rather than keeping a reference to the original pixmap. However, I > don't believe that's how the X.org server actually implements it. No, it keeps a reference, but not through the Pixmap ID, so while the client can destroy the ID, the server holds a reference to the underlying Pixmap structure itself. No copy is made. -- keith.pack...@intel.com pgphr9JDxqSD6.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XSetBackgroundPixmap question
> The combination of the documentation and the observed behaviour > implies that the X server *may* copy the pixmap data or it may just > keep a reference. Either way, deleting the pixmap after setting it > should be fine, but modifying a pixmap which has been used as a > background pixmap has undefined behaviour. What is undefined behavior? Modifying a pixmap that is still used as a background pixmap, modifying a pixmap that was used as a background pixmap but has since been replaced, or both of these cases? ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XSetBackgroundPixmap question
James Buren writes: > Wow, that was fast. Thanks. Some other questions I've been having. I've been > considering using > the XRender extension and I've noticed the documentation is nearly > non-existent. What advantages > does it offer over older Xlib drawing API? At the very least, it seems to > offer more complex graphics > operations like scaling and alpha blending. You should look at cairo instead -- it nicely wraps the render extension with a pretty postscript-like API. -- keith.pack...@intel.com pgpAzRRJkjwIZ.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XSetBackgroundPixmap question
Wow, that was fast. Thanks. Some other questions I've been having. I've been considering using the XRender extension and I've noticed the documentation is nearly non-existent. What advantages does it offer over older Xlib drawing API? At the very least, it seems to offer more complex graphics operations like scaling and alpha blending. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: XSetBackgroundPixmap question
[I presume that you mean XSetWindowBackgroundPixmap; there is no Xlib function named XSetBackgroundPixmap.] James Buren wrote: > When using this Xlib function to set a new background pixmap, how does the > old one get > freed? If I am setting the root window's background pixmap, I don't know how > I can get the > XID of the old one. If it is a window I created, I can cache it but that > seems overkill if I'm > just wanting to discard the old one. Can someone direct me to how I am > supposed to free > the old background pixmap? Thanks. The manual page for XSetWindowBackgroundPixmap says: The XSetWindowBackgroundPixmap function sets the background pixmap of the window to the specified pixmap. The background pixmap can immediately be freed if no further explicit references to it are to be made. That seems to imply that the X server makes a copy of the pixmap data rather than keeping a reference to the original pixmap. However, I don't believe that's how the X.org server actually implements it. I've encountered code which uses a background pixmap to implement a persistent screen, and drawing to the pixmap then calling XClearWindow (without calling XSetWindowBackgroundPixmap in between) results in the updated pixmap contents appearing in the window. So it appears to use reference counting or similar. The combination of the documentation and the observed behaviour implies that the X server *may* copy the pixmap data or it may just keep a reference. Either way, deleting the pixmap after setting it should be fine, but modifying a pixmap which has been used as a background pixmap has undefined behaviour. Regardless of the implementation, there isn't any way to query the current background pixmap. The background_pixmap field in the XSetWindowAttributes structure used by XChangeWindowAttributes isn't present in the XWindowAttributes structure used by XGetWindowAttributes. -- Glynn Clements ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
XSetBackgroundPixmap question
When using this Xlib function to set a new background pixmap, how does the old one get freed? If I am setting the root window's background pixmap, I don't know how I can get the XID of the old one. If it is a window I created, I can cache it but that seems overkill if I'm just wanting to discard the old one. Can someone direct me to how I am supposed to free the old background pixmap? Thanks. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
