Age | Commit message (Collapse) | Author | Files | Lines |
|
References to other servers in configure.ac are left in place since
they may set variables used when compiling.
|
|
xprint was still in xorg-xserver at 1.5.3 and was removed in 1.5.99.1.
Hence the next version of standalone xprint should be 1.6.0.
|
|
libXfont 1.4 removed Xprint font support, so need built-in fonts:
Need ./configure --enable-builtin-fonts
However this causes unresolved segfaults in client programs.
The default situation (--disable-builtin-fonts) successfully uses
external fonts but only builds against libXfont 1.3.
Also included suggestion to use libcairo instead of Xprint for those who
need the WYSIWYG or print-to-pdf/postscript functionality.
|
|
This reverts commit f7b940677eae414ab08ce41fe6bdb7253b7a7864.
The built-in fonts (--enable-builtin-fonts) trigger a segfault with
clients. That is, Xprt will build and run successfully with them, but
when a client such as xpsimplehelloworld tries to print via Xprt, it
segfaults. Since Xprint is deprecated, motivation is not high for
fully debugging this problem.
The workaround around will be to not use built-in fonts (i.e.
reverting the previous commit to use --disable-builtin-fonts by
default again), and build against libXfont 1.3 (rather than the latest
libXfont 1.4, which has Xprint support removed).
|
|
Copied from http://xprint.mozdev.org/docs/Xprint_FAQ.html.
Useful document.
|
|
BUILTIN_FONTS, used by dix/dixfonts.c, is now defined by default via
the builtin-fonts variable in the configure scripts. It may be
disabled by using ./configure --disable-builtin-fonts.
This has been done since Xprint support was removed from libXfont 1.4.
If built-in fonts are disabled then PrinterFontRegisterFpeFunctions,
FontFileCheckRegisterFpeFunctions and check_fs_register_fpe_functions
will not be defined in dix/dixfonts.c, when libXfont 1.4 is used (they
were previously defined by libXfont 1.3). Hence, assume built-in fonts
are used by default.
(see also commit 6f47f7c0585c2b621c39cae9eef2a04d7f81bcc0 ).
|
|
git+ssh://git.debian.org/git/pkg-xorg/xserver/xprint into upstream-unstable
|
|
With this commit, Xprt gets "built-ins" appended to its FontPath.
Fixes the "could not open default font 'fixed'" problem; required now
that libxfont 1.4 does not support Xprint.
Adapted from xserver-xorg commit f56cbe1ef24415d0142b9a7d0ab0a031069ccb52
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
modinit.h had been part of hw/xfree86/dixmods/extmod, enabling
initialisation of extension modules. Xprint does not implement
extension modules, so the header file is provided as a dummy file
instead, now that the xprint ddx is separated from the xfree86 ddx..
|
|
|
|
infinite exec loop with new /usr/X11/bin/Xquartz and older X11.app
(cherry picked from commit 78032815aeb10c22ff45b49702e9c9df82ab471c)
|
|
(cherry picked from commit 3b0afb47c3d8ad922cb2315ed8034f4d77d4a249)
|
|
launchd, ApplicationServices, and Dock support
(cherry picked from commit 9b67fca9b7d3050d3d5582a5210270db7eb2ed05)
|
|
The -wm (when mapped) option for the BackingStore support has been
causing the server to dereference a NULL pointer.
This has probably been the case since backing store has been
implemented on top of Composite.
It looks like (some of?) Composite didn’t expect its WIndowPtr
argument to be the root window.
In Composite’s compCheckRedirect() function we now avoid calling
compAllocPixmap() and compFreePixmap() when the pWin pointer’s
parent member is NULL, as is it the case with a server’s root window.
This addresses:
https://bugs.freedesktop.org/show_bug.cgi?id=15878
|
|
|
|
|
|
KdInitOutput() used to enable Composite when it was disabled by default,
but now this hack prevents ``-extension Composite'' from working.
Remove it, as Composite is enabled by default anyway.
|
|
Part of fix for Sun bug 4258475
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4258475>
|
|
upstream-experimental
|
|
Use dummy config functions to replace those from config/config.c, and
therefore do not link Xprt with $CONFIG_LIB.
Works around an endlessly spinning loop in dix/dispatch.c::Dispatch()
(WaitForSomething() not waiting) when built with dbus, which was
causing Xprt to use 95% cpu.
|
|
startup work.
(cherry picked from commit 2232c91d5c277673929eab2abb5e0495c00877cb)
|
|
(cherry picked from commit cd4d2355e227549a3410485a130549dd91ccdcfe)
|
|
(cherry picked from commit 8a0524b30e1e860f3ae35741c116fc8da28aef79)
|
|
(cherry picked from commit 330ffad5477e32c5ab9ed338bc628bd5ae9f4c98)
|
|
(cherry picked from commit ff085deba18682caa2f93d61a75b38db87d747b1)
|
|
The HAL spec says that input.xkb.{rmlv}* can be sent, but if the user
specifies a X-specific {rmlv}, then this is overridden through the use of
input.x11_options.Xkb{RMLV}.
However, the way how the server parses options--by ignoring capitalisation,
underscores and spaces--the HAL and the x11_options would override each other.
So we simply filter the options, letting Xkb{RMLV} override xkb_{rmlv} and
only actually add them to the device after parsing _all_ options.
* rmlv ... rules, model, layout, variant
See Bug 13037 <http://bugs.freedesktop.org/show_bug.cgi?id=13037>
(cherry picked from commit fc35d1e3be201e3821413bb2eeb8d43e1e56ba17)
|
|
It makes my vim look ugly. Put "let c_space_errors=1" into your .vimrc.
(cherry picked from commit 1f54c05cf8a6b82e5fc6362f7f8e8fdc2444b9e8)
|
|
Turns out this just caused segfaults further down the line. Oops.
This reverts commit 268d61e00cf4bc52c05f19eda7ab4f6accce12c8.
|
|
|
|
|
|
When something went wrong building a keymap, try to explain to the user
what it actually was, instead of the dreaded 'Failed to load XKB keymap'
catch-all.
|
|
This shuts up a warning.
|
|
GLX, there's more to the world than just you. If you fail to load the
software renderer, don't bring the entire server down.
The error path probably needs better testing on this one, but it seems
mostly okay to me.
|
|
Glyph bits are now stored in a proper pixmap, not just hanging off the
end of a GlyphRec.
|
|
Builders can force one or the other by passing SHA1_LIB & SHA1_CFLAGS
to configure
|
|
Since glyphs are stored in pixmaps now, they can make their way into VRAM,
which invalidates a bunch of fast-path assumptions in the XAA code. Thus
you end up doing color-expands or WriteBitmap from la-la land and your
aliased glyphs go all funny.
Since XAA isn't ever growing the ability to do sane glyph accel, just force
glyph pixmaps into host memory by catching them at CreatePixmap time.
|
|
(cherry picked from commit 56b7988d2662caa4d31094695b414080e4470ed4)
|
|
(cherry picked from commit e414ec462cfc63f8eb7f504f526f5a2c73f51e69)
|
|
(cherry picked from commit f225222ba2bf4f03425107f258d60b73c88efaec)
|
|
in prep for startup rewrite
(cherry picked from commit 453a982e6382cff06ea27abba225440b07068f50)
|
|
(cherry picked from commit b7a1a640cef8c69442859cbf89034ad362a19684)
|
|
|
|
(cherry picked from commit c1ec36e28cff857664090cc8792db1ae93b783fa)
|
|
The composite overlay window code had several misunderstandings of the
workings of the X server, in particular error handling paths would often
double-free objects. Clean all of this up by using resource destruction as
the sole mechanism for freeing resource-based objects.
|
|
Thanks to Owen Taylor for root-causing this one.
If a TreatAsTransparent window has any area in the borderClip, that will be
added to the totalClip region for use by other windows. That's wrong.
Instead, simply empty the borderClip for TreatAsTransparent windows right up
front.
|
|
|
|
like negative (x,y) values
(cherry picked from commit 8d9eab3a2ec5955cc2698fdcb1fa6ed12b2aadb7)
|
|
(cherry picked from commit ff10c37bdd09656cf2f7ee9577f5552caa1ffdb8)
|
|
(cherry picked from commit f2020b9836bacd0593ac0b4c8541e32714ab02a9)
|