Re: Xserver driver merging pros & cons
On Don, 2011-09-15 at 15:12 -0700, Chase Douglas wrote: > On 09/15/2011 02:41 PM, Matt Turner wrote: > > On Thu, Sep 15, 2011 at 11:45 AM, Jesse Barnes > > wrote: > >> Pros: > >> 1) easier to propagate API changes across drivers (just like Linux) > >> 1a) thus easier to change ABI > > > > I suppose that's true. How often are we breaking the ABI though? How > > often do we break the ABI and it doesn't get fixed in the drivers we > > care about within a day or so? It's strange to sort of pretend that we > > care about other drivers simply for the point of this argument. > > This needs an extra sub-point: > 1b) thus easier to git-bisect issues > > The problems enterprise distros may have with merging the drivers back > into the server may be offset by this point. I used to work in a much > more enterprise-like distro role before I began at Canonical, and I can > attest that bisectable sources were a *big* win when a bug was > reproducible and the sources could actually be bisected. The current X > approach fails the latter condition. It's not impossible now (been there, done that), though you're certainly right it would be easier. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI 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] fb: Rename wfbTriangles and wfbTrapezoids
On Sep 15, 2011, at 9:29 PM, Alan Coopersmith wrote: > On 09/14/11 15:25, Aaron Plattner wrote: >> These symbols were not renamed when they were added to libfb: >> >> # nm -D libwfb.so | grep ' fb' >> 00028d00 T fbTrapezoids >> 00028d60 T fbTriangles >> >> This causes corruption and/or crashes on wfb-ful drivers like nvidia: > > Is there any simple/portable way to automate the name list generation or > at least test that it's correctly done at build time? It would be nice > to not have to worry about manual updates being needed for every change. > > On Solaris, I can get the equivalent output with: > > % nm -pg libwfb.so | grep ' fb' > 00218380 T fbTrapezoids > 00219112 T fbTriangles > > but I'm not sure that's the best test, and clearly would need portability > help. wfb seems like a candidate for -export-symbols-regex '^wfb.*' but > then it would be even harder to detect problems. > > If nothing else, should there be a comment early on in fb/*.h advising > people when a wfbrename.h entry would be needed? > > And presumably because of the crashes this is a 1.11 stable release > candidate as well, right? Yes. I'll cherry-pick it once it lands on master. Keith, can you please go through your PULL/PATCH queue this weekend, so I can get an rc1 out next week? Thanks. ___ 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 3/3] xfree86: Link modules with -module
Ah good catch. Removed in my tree. On Sep 15, 2011, at 8:55 PM, Alan Coopersmith wrote: > >> diff --git a/hw/xfree86/ramdac/Makefile.am b/hw/xfree86/ramdac/Makefile.am >> index 3c37805..d29ded5 100644 >> --- a/hw/xfree86/ramdac/Makefile.am >> +++ b/hw/xfree86/ramdac/Makefile.am >> @@ -1,5 +1,6 @@ >> noinst_LTLIBRARIES = libramdac.la >> >> +libramdac_la_LDFLAGS = -module -avoid-version >> libramdac_la_SOURCES = xf86RamDac.c xf86RamDacCmap.c \ >>xf86Cursor.c xf86HWCurs.c IBM.c BT.c TI.c \ >>xf86BitOrder.c > > Is this needed since libramdac isn't an installed module? At least for me > it builds a static libramdac.a not a shared object at all. > > -- > -Alan Coopersmith-alan.coopersm...@oracle.com >Oracle Solaris Platform Engineering: X Window System > --- Jeremy Huddleston Rebuild Sudan - Board of Directors - http://www.rebuildsudan.org Berkeley Foundation for Opportunities in Information Technology - Advisory Board - http://www.bfoit.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
> If you're talking enterprise distros though, that means committing to at > least one long-term support stable branch, that you backport new driver > support to > for years, not just the 6 months until the next one. Just a note from an enterprise distro maintainer, we are currently rebasing the X server/Mesa stacks as much as we can. The problem with doing backports is you end up running combinations of totally untested variants from upstream. Like does anyone upstream run Xorg ATI 6.14.2 against Xserver 1.1? of course not. The thing is that although of the driver code that is compatible with older servers, there is <100-x> of the code that has subtle bugs that aren't obvious ABI breaks. Inherent reliance on fixes in the fb layer, EXA layer, damage, randr layers etc is nearly impossible to find in advance. Like if Intel made SNA the default, the number of server fixes it requires to operate correctly is major, whereas it'll build against any of those servers at an ABI level. Dave. ___ 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 fonts-util 1/2] Never run fc-cache if cross-compiling
On 09/12/11 07:18, Jon TURNEY wrote:
Since the cache files produced by fc-cache are arch-dependent, there is
no point in running fc-cache if cross-compiling
So, even if we aren't using a DESTDIR, but are installing directly into
(a hopefully non-default) prefix, don't run fc-cache when cross-compiling
(Particularly, this avoids running fc-cache when cross-compiling following
the instructions at [1])
[1] http://www.x.org/wiki/CrossCompilingXorg
Signed-off-by: Jon TURNEY
---
fontutil.m4.in |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fontutil.m4.in b/fontutil.m4.in
index b2b9bd8..f040e19 100644
--- a/fontutil.m4.in
+++ b/fontutil.m4.in
@@ -160,15 +160,16 @@ AC_DEFUN([XORG_FONT_REQUIRED_PROG],[
#
# Set FCCACHE to path to fc-cache (fontconfig cache builder) if found
# Set RUN_FCCACHE to a rule suitable for substituting into a makefile
-# to run fc-cache if found and not installing to $DESTDIR
+# to run fc-cache if found and not installing to $DESTDIR and not
+# cross-compiling
#
# fc-cache is optional, not required, and should be skipped when making
-# packages (installing to $DESTDIR).
+# packages (installing to $DESTDIR) or cross-compiling
#
AC_DEFUN([XORG_FONT_FCCACHE],[
AC_PATH_PROG(FCCACHE, fc-cache)
FCCACHE_WARN='echo "** Warning: fonts.cache not built" ; echo "** Generate
this file manually on host system using fc-cache"'
- if test x"$FCCACHE" = x ; then
+ if test x"$FCCACHE" = x || test x"$cross_compiling" != x"no" ; then
RUN_FCCACHE="${FCCACHE_WARN}"
else
RUN_FCCACHE='@(if test -z "$(DESTDIR)"; then echo $(FCCACHE)
$(fontdir); $(FCCACHE) $(fontdir); else'
Reviewed-by: Alan Coopersmith
--
-Alan Coopersmith-alan.coopersm...@oracle.com
Oracle Solaris Platform Engineering: X Window System
___
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 fonts-util 2/2] If cross-compiling, we don't have to run mkfontdir
On 09/12/11 07:18, Jon TURNEY wrote: +# XORG_FONT_MKFONTDIR() +# --- +# Minimum version: 1.1.1 Shouldn't that be 1.3.0 since we already released 1.2.0? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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 libICE] specs: use DocBook suggested markup for Copyrights
On 09/11/11 14:08, Gaetan Nadon wrote: Puts the statement on a single line, using commas to separate years --> Copyright © 1993, 1994, 1996 X Consortium As opposed to 3 double-spaced lines. Signed-off-by: Gaetan Nadon --- doc/ICElib.xml |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/ICElib.xml b/doc/ICElib.xml index 3a883df..d239bf2 100644 --- a/doc/ICElib.xml +++ b/doc/ICElib.xml @@ -19,9 +19,10 @@ X Consortium -1993X Consortium -1994X Consortium -1996X Consortium + +199319941996 +X Consortium + Yes, please. I've fixed a couple docs before but not had time to do a full search of all docs/modules. Reviewed-by: Alan Coopersmith -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 8/8] Remove unused vtSysreq
On 09/15/11 20:51, Jamey Sharp wrote: On Thu, Sep 15, 2011 at 06:42:59PM -0700, Alan Coopersmith wrote: On 09/15/11 13:07, Jamey Sharp wrote: It looks to me like you should also delete VTSYSRQ from hw/xfree86/parser/xf86tokens.h. Please ensure that any changes result in the X server simply ignoring the VTSysReq option in existing xorg.conf and not erroring out& refusing to start on a file that happens to have a no-longer-useful option in. If I understand the parser correctly (and I probably don't), it's already too late for that: while there's a VTSYSRQ entry in the enum in xf86tokens.h, nothing generates that token type. Instead, there's a VTSysReq ServerFlag. So deleting the token from the enum is not a regression, I think. I can't figure out at a quick glance whether unknown ServerFlags are treated as an error, though. Does the patch need to somehow make this flag be explicitly ignored if present? Honestly, I don't remember - probably easiest to just test starting the server (when built with this series) using an xorg.conf with the entry added. I just remember prior issues here (see commits e0a451eb7cc & d2cf562bbad from prior obsoletion - though those seem to be keywords, not options) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 8/8] Remove unused vtSysreq
On Thu, Sep 15, 2011 at 06:42:59PM -0700, Alan Coopersmith wrote: > On 09/15/11 13:07, Jamey Sharp wrote: > >It looks to me like you should also delete VTSYSRQ from > >hw/xfree86/parser/xf86tokens.h. > > Please ensure that any changes result in the X server simply ignoring > the VTSysReq option in existing xorg.conf and not erroring out & refusing > to start on a file that happens to have a no-longer-useful option in. If I understand the parser correctly (and I probably don't), it's already too late for that: while there's a VTSYSRQ entry in the enum in xf86tokens.h, nothing generates that token type. Instead, there's a VTSysReq ServerFlag. So deleting the token from the enum is not a regression, I think. I can't figure out at a quick glance whether unknown ServerFlags are treated as an error, though. Does the patch need to somehow make this flag be explicitly ignored if present? Jamey signature.asc Description: 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 v2 7/7] dix: NewCurrentScreen must work on pointers where possible
On Fri, 2 Sep 2011 11:36:51 +1000, Peter Hutterer
wrote:
> void
> NewCurrentScreen(DeviceIntPtr pDev, ScreenPtr newScreen, int x, int y)
> {
> -SpritePtr pSprite = pDev->spriteInfo->sprite;
> +DeviceIntPtr ptr;
> +SpritePtr pSprite;
> +
> +ptr = IsFloating(pDev) ? pDev : GetXTestDevice(GetMaster(pDev,
> MASTER_POINTER));
This assumes that any floating device passed to NewCurrentScreen is a
pointer device, right?
--
keith.pack...@intel.com
pgpzrrJHG8tGh.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] configure.ac: Remove unreachable check for VM86 headers.
On Thu, Sep 15, 2011 at 07:28:25PM -0400, Gaetan Nadon wrote: > On Wed, 2011-09-14 at 10:07 -0500, Jamey Sharp wrote: > > "configure --with-int10=yes" is not a valid configuration, and the check > > It depends what is the definition of "valid" in this context. Running > "./configure --with-int10" will set "INT10" to "yes". You may choose to > ignore this value. I can only guess that current code checked for "yes" > as a means to provide a default value when no backend was specified. On further investigation: Daniel Stone introduced the block I'm proposing to delete in commit 588105173840355717d7b2f7f652289a41166c3f from 2005, with a commit message beginning "Huge cleanup." It appears that he intended that patch to mostly be a reorganization of configure.ac, not to change functionality, so I'm not sure how this snuck in. Otherwise, as far as I can tell, there's never been an attempt to support INT10=yes. > > for sys/vm86.h and sys/io.h is not used. Delete it. > > I agree with ignoring "yes". I don't recall any other module using it in > that way. Just be prepared in the case where someone did use it. It's > not really dead code, but close enough. > > The default value is either x86emu or stub for FreeBSD on a PowerPC. Any > unrecognized value (such as yes, no or vn86) will not build any int10 > backend. No warnings or errors. Hopefully the builder will have some way > of finding out why it does not work. The library builds with just the > common code. "vn86" is an excellent example. This does seem error-prone. But: > Suggestion: > > AS_HELP_STRING([--with-int10=BACKEND], [vm86, x86emu or stub > (default:auto)]), > > AC_MSG_ERROR if no valid value is given Can you suggest a patch that does that? I don't see any way to report such an error without copying the list of possible backends yet another time. > Verify if there is a need to check for the headers. The code as > it is was probably the result of changes around it rather than > the intention of the developer. Not as far as I can tell; and since nobody could have gotten a usable int10 module with --with-int10, and the AC_CHECK_HEADERS is only used in that case, I don't think anybody is relying on it. So is there some reason not to apply this patch as-is? Thanks for looking this over! Jamey signature.asc Description: 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] configure.ac: Remove unreachable check for VM86 headers.
On 09/14/11 09:11, Jamey Sharp wrote: On Wed, Sep 14, 2011 at 10:39:53AM -0500, Alan Coopersmith wrote: On 09/14/11 10:07 AM, Jamey Sharp wrote: "configure --with-int10=yes" is not a valid configuration, and the check for sys/vm86.h and sys/io.h is not used. Delete it. AM_CONDITIONAL(INT10_VM86, [test "x$INT10" = xvm86]) AM_CONDITIONAL(INT10_X86EMU, [test "x$INT10" = xx86emu]) AM_CONDITIONAL(INT10_STUB, [test "x$INT10" = xstub]) -if test "x$INT10" = xyes; then - dnl VM86 headers - AC_CHECK_HEADERS([sys/vm86.h sys/io.h]) -fi Should that be checking for "x$INT10" = xvm86 since it's checking for the vm86 headers? Perhaps AC_ERRORing if vm86 is requested and they're not found? Oddly, nothing in-tree #includes sys/vm86.h, not even the INT10_VM86 implementation. So no, I think this block should just die. Some things do #include sys/io.h, but they aren't related to int10 and didn't use HAVE_SYS_IO_H. Okay then, since this makes --with-int10=yes no more broken than it was before, Reviewed-by: Alan Coopersmith Though if it really does produce a broken system, another patch to AC_MSG_ERROR out when --with-int10= is passed something other than one of the valid values would be good too. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: Rename wfbTriangles and wfbTrapezoids
On 09/14/11 15:25, Aaron Plattner wrote: These symbols were not renamed when they were added to libfb: # nm -D libwfb.so | grep ' fb' 00028d00 T fbTrapezoids 00028d60 T fbTriangles This causes corruption and/or crashes on wfb-ful drivers like nvidia: Is there any simple/portable way to automate the name list generation or at least test that it's correctly done at build time? It would be nice to not have to worry about manual updates being needed for every change. On Solaris, I can get the equivalent output with: % nm -pg libwfb.so | grep ' fb' 00218380 T fbTrapezoids 00219112 T fbTriangles but I'm not sure that's the best test, and clearly would need portability help. wfb seems like a candidate for -export-symbols-regex '^wfb.*' but then it would be even harder to detect problems. If nothing else, should there be a comment early on in fb/*.h advising people when a wfbrename.h entry would be needed? And presumably because of the crashes this is a 1.11 stable release candidate as well, right? BTW, is it a problem that libfb & libwfb each have a local copy of fbOverlayScreenPrivateKeyRec ? Or is it required that wfbOverlayFinishScreenInit initialize a different private than fbOverlayFinishScreenInit and fbOverlayScreenPrivateKeyRec should be added to the rename list to simplify finding the right one when debugging? -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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 3/3] xfree86: Link modules with -module
diff --git a/hw/xfree86/ramdac/Makefile.am b/hw/xfree86/ramdac/Makefile.am index 3c37805..d29ded5 100644 --- a/hw/xfree86/ramdac/Makefile.am +++ b/hw/xfree86/ramdac/Makefile.am @@ -1,5 +1,6 @@ noinst_LTLIBRARIES = libramdac.la +libramdac_la_LDFLAGS = -module -avoid-version libramdac_la_SOURCES = xf86RamDac.c xf86RamDacCmap.c \ xf86Cursor.c xf86HWCurs.c IBM.c BT.c TI.c \ xf86BitOrder.c Is this needed since libramdac isn't an installed module? At least for me it builds a static libramdac.a not a shared object at all. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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 3/3] xfree86: Link modules with -module
On 09/15/11 05:57, Gaetan Nadon wrote: A couple of things to verify: * OpenBSD still uses libtool 1.5 So does Solaris - 1.5.22, though I have a local install of 2.2 I usually use for building X.Org modules from git. I don't think that's an issue though, as -module has worked fine for us for many years - it's already used for several modules in the xserver tree: hw/xfree86/dri/Makefile.am:libdri_la_LDFLAGS = -module -avoid-version @LIBDRM_LIBS@ hw/xfree86/dri2/Makefile.am:libdri2_la_LDFLAGS = -module -avoid-version @LIBDRM_LIBS@ hw/xfree86/i2c/Makefile.am:bt829_drv_la_LDFLAGS = -module -avoid-version [and many more in that file] * Solaris is different enough to get a review for this Also see no problems here, as noted above with the modules that use it and work fine. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 8/8] Remove unused vtSysreq
On 09/15/11 13:07, Jamey Sharp wrote: It looks to me like you should also delete VTSYSRQ from hw/xfree86/parser/xf86tokens.h. Please ensure that any changes result in the X server simply ignoring the VTSysReq option in existing xorg.conf and not erroring out & refusing to start on a file that happens to have a no-longer-useful option in. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On 09/15/11 14:01, Jeremy Huddleston wrote: On Sep 15, 2011, at 3:30 PM, Chase Douglas wrote: On 09/15/2011 01:00 PM, Jeremy Huddleston wrote: On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote: From distro package maintainer point of view I _love_ split drivers. It's so much easier to packages these, rebuild when needed (one faulty, not building, driver doesn't stop whole build process), easier to patch and backport fixes. I don't see how it is easier. git-cherry-pick should do most of that for you just like it currently does. You'd just be doing it in a clone of xorg-server rather than a clone of xf86-video-* I think this is mixing two issues. Yes, cherry picking individual commits to get a "newer" driver that still works with an older server is not terribly difficult. However, you seem to be advocating that the consumers (distros) should do this. Currently, X.org is doing this by providing upstream drivers that work against multiple server versions. No, I'm not placing the burden on the distros to do all the work. It's X.org's responsibility to ensure that relevant fixes land in our stable releases. Fixes that add support for new hardware in an unobtrusive way and changes which fix real bugs are great candidates for cherry-picking into the stable branch. If a distro wants something even earlier, they can cherry-pick it themselves, but this is no different than pulling in changes from an unreleased driver currently. Driver maintainers will have their own xorg-server tree living on github, git.fd.o, or whatever, and we'll merge changes from there into xserver. If you're talking enterprise distros though, that means committing to at least one long-term support stable branch, that you backport new driver support to for years, not just the 6 months until the next one. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On 09/15/11 14:41, Matt Turner wrote: 4) increased test coverage for the server as users wanting current driver code will be building new servers too Maybe. I'd hate to force users to do that just to get new hardware support or a simple driver bug fix. The server will often require you to update your proto modules too (possibly multiple ones of them, since we've still never unmodularized those, despite taking that discussion all the way to prototype before abandoning multiple times), where most driver updates will not. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On 09/15/11 08:45, Jesse Barnes wrote: Cons: 1) more work for distros to backport just driver changes to old servers (especially if people follow through on (3) above) 1a) if backporting is harder, new hardware support will be more difficult to land in "enterprise" level distros Also ties server releases more tightly to kernel support, especially un-fun for those running a kernel that's not Linux (i.e. BSD & Solaris). I was able to ship older Intel drivers that still supported UMS, while waiting for KMS support to land in our kernel. If Radeon similarly goes KMS only, I'll probably have to do the same for it for a while, since DRM porting to another kernel is no small/quick task. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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 xserver 3/3] devbook.am: maintenance update from docbook.am
The developer docs are generated from a subset of docbook.am which is sometimes updated. The one difference for xserver is the embedded css style in the HEAD element. Reviewed-by: Jeremy Huddleston Signed-off-by: Gaetan Nadon --- devbook.am | 45 +++-- 1 files changed, 19 insertions(+), 26 deletions(-) diff --git a/devbook.am b/devbook.am index 4e23bb7..400b2ca 100644 --- a/devbook.am +++ b/devbook.am @@ -20,43 +20,36 @@ noinst_DATA = # DocBook/XML file with chapters, appendix and images it includes dist_noinst_DATA = $(docbook) $(chapters) -# -# Generate DocBook/XML output formats with or without stylesheets -# - -# Stylesheets are available if the package xorg-sgml-doctools is installed if HAVE_STYLESHEETS -# The location where all cross reference databases are installed -XMLTO_FLAGS = \ - --searchpath "$(XORG_SGML_PATH)/X11"\ +XMLTO_HTML_FLAGS = \ + --searchpath "$(XORG_SGML_PATH)/X11"\ --searchpath "$(abs_top_builddir)" \ - --stringparam current.docid="$(<:.xml=)" - -XMLTO_XHTML_FLAGS = \ - -m $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl \ - --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css - -XMLTO_FO_FLAGS = \ - -m $(STYLESHEET_SRCDIR)/xorg-fo.xsl -endif HAVE_STYLESHEETS + -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl noinst_DATA += $(docbook:.xml=.html) %.html: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) xhtml-nochunks $< + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $< + +if HAVE_XMLTO_TEXT +noinst_DATA += $(docbook:.xml=.txt) +%.txt: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< +endif HAVE_XMLTO_TEXT if HAVE_FOP +XMLTO_FO_FLAGS = \ + --searchpath "$(XORG_SGML_PATH)/X11"\ + --searchpath "$(abs_top_builddir)" \ + --stringparam img.src.path=$(abs_builddir)/ \ + -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl + noinst_DATA += $(docbook:.xml=.pdf) $(docbook:.xml=.ps) %.pdf: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop pdf $< + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $< %.ps: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop ps $< + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $< endif HAVE_FOP - -if HAVE_XMLTO_TEXT -noinst_DATA += $(docbook:.xml=.txt) -%.txt: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) txt $< -endif HAVE_XMLTO_TEXT +endif HAVE_STYLESHEETS CLEANFILES = $(noinst_DATA) -- 1.7.4.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
[PATCH xserver 2/3] docbook.am: embed css styles inside the HTML HEAD element
Rather than referring to the external xorg.css stylesheet, embed the content of the file in the html output produced. This is accomplished by using version 1.10 of xorg-xhtml.xsl. This makes the whole html docs tree much more relocatable. In addition, it eliminates xorg.css as a runtime file which makes xorg-sgml-doctools a build time only package. Reviewed-by: Jeremy Huddleston Signed-off-by: Gaetan Nadon --- docbook.am |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/docbook.am b/docbook.am index 9377f5b..bba4d54 100644 --- a/docbook.am +++ b/docbook.am @@ -30,11 +30,9 @@ XMLTO_HTML_OLINK_FLAGS = \ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \ --stringparam current.docid="$(<:.xml=)" XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl -XMLTO_HTML_CSS_STYLESHEET_FLAGS = --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css XMLTO_HTML_FLAGS = \ $(XMLTO_SEARCHPATH_FLAGS) \ $(XMLTO_HTML_STYLESHEET_FLAGS) \ - $(XMLTO_HTML_CSS_STYLESHEET_FLAGS) \ $(XMLTO_HTML_OLINK_FLAGS) shelf_DATA += $(docbook:.xml=.html) -- 1.7.4.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
[PATCH xserver 1/3] docbook.am: global maintenance update - entities, images and olinking
Adding support in libX11 for html chunking caused a reorg of docbook.am as well as the xorg-sgml-doctools masterdb for olinking. The parameter img.src.path is added for pdf images. A searchpath to the root builddir is added for local entities, if present. This feature was initiated by xserver module and made available to all. The docbook.am makefile hides all the details and is identical for all 22 modules having DocBook documentation. It is included by a thin Makefile.am which requires no docbook knowledge. Reviewed-by: Jeremy Huddleston Signed-off-by: Gaetan Nadon --- docbook.am | 116 1 files changed, 62 insertions(+), 54 deletions(-) diff --git a/docbook.am b/docbook.am index eb3bf0c..9377f5b 100644 --- a/docbook.am +++ b/docbook.am @@ -21,76 +21,84 @@ shelf_DATA = dist_shelf_DATA = $(docbook) $(chapters) if HAVE_XMLTO -# -# Generate DocBook/XML output formats with or without stylesheets -# - -# Stylesheets are available if the package xorg-sgml-doctools is installed if HAVE_STYLESHEETS -# The location where all cross reference databases are installed -sgmldbsdir = $(XORG_SGML_PATH)/X11/dbs -masterdb = "$(sgmldbsdir)/masterdb$(suffix $@).xml" -XMLTO_FLAGS = \ - --searchpath "$(XORG_SGML_PATH)/X11"\ - --searchpath "$(abs_top_builddir)" \ - --stringparam target.database.document=$(masterdb) \ - --stringparam current.docid="$(<:.xml=)"\ - --stringparam collect.xref.targets="no" - -XMLTO_XHTML_FLAGS = \ - -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl \ - --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css - -XMLTO_FO_FLAGS = \ - -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl -endif HAVE_STYLESHEETS +XMLTO_SEARCHPATH_FLAGS = \ + --searchpath "$(XORG_SGML_PATH)/X11"\ + --searchpath "$(abs_top_builddir)" +XMLTO_HTML_OLINK_FLAGS = \ + --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \ + --stringparam current.docid="$(<:.xml=)" +XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl +XMLTO_HTML_CSS_STYLESHEET_FLAGS = --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css +XMLTO_HTML_FLAGS = \ + $(XMLTO_SEARCHPATH_FLAGS) \ + $(XMLTO_HTML_STYLESHEET_FLAGS) \ + $(XMLTO_HTML_CSS_STYLESHEET_FLAGS) \ + $(XMLTO_HTML_OLINK_FLAGS) shelf_DATA += $(docbook:.xml=.html) -%.html: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) xhtml-nochunks $< - -if HAVE_FOP -shelf_DATA += $(docbook:.xml=.pdf) $(docbook:.xml=.ps) -%.pdf: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop pdf $< -%.ps: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop ps $< -endif HAVE_FOP +%.html: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $< if HAVE_XMLTO_TEXT + shelf_DATA += $(docbook:.xml=.txt) %.txt: %.xml $(chapters) - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) txt $< + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< endif HAVE_XMLTO_TEXT -# -# Generate documents cross-reference target databases -# +if HAVE_FOP +XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/ +XMLTO_PDF_OLINK_FLAGS = \ + --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \ + --stringparam current.docid="$(<:.xml=)" +XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl + +XMLTO_FO_FLAGS = \ + $(XMLTO_SEARCHPATH_FLAGS) \ + $(XMLTO_FO_STYLESHEET_FLAGS)\ + $(XMLTO_FO_IMAGEPATH_FLAGS) \ + $(XMLTO_PDF_OLINK_FLAGS) + +shelf_DATA += $(docbook:.xml=.pdf) +%.pdf: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $< -# This is only possible if the xorg-sgml-doctools package is installed -if HAVE_STYLESHEETS -if HAVE_XSLTPROC +shelf_DATA += $(docbook:.xml=.ps) +%.ps: %.xml $(chapters) + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $< +endif HAVE_FOP -# DocBook/XML generated document cross-reference database -shelf_DATA += $(docbook:.xml=.html.db) $(docbook:.xml=.fo.db) +# Generate documents cross-reference target databases +if HAVE_XSLTPROC -# Generate DocBook/XML document cross-reference database -# Flags for the XSL Transformation processor generating xref target databases -XSLTPROC_FLAGS = \ +XSLT_SEARCHPATH_FLAGS =\ --path "$(XORG_SGML_PATH)/X11" \ - --path "$(abs_top_builddir)"\ - --stringp
Re: [PATCH libXi] inputlib: restore original title "X Input Device Extension Library"
On 09/15/11 09:01, Gaetan Nadon wrote: Somehow the title got changed during troff to docbook conversion. Latest troff version: ftp://www.x.org/pub/X11R7.0/doc/PDF/XiLib.pdf Signed-off-by: Gaetan Nadon --- specs/inputlib.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/specs/inputlib.xml b/specs/inputlib.xml index bfbf862..4be875a 100644 --- a/specs/inputlib.xml +++ b/specs/inputlib.xml @@ -8,7 +8,7 @@ -X11 Input Extension Protocol Specification +X Input Device Extension Library X Version 11, Release&fullrelvers; Version 1.0 Reviewed-by: Alan Coopersmith -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure.ac: Remove unreachable check for VM86 headers.
On Wed, 2011-09-14 at 10:07 -0500, Jamey Sharp wrote: > "configure --with-int10=yes" is not a valid configuration, and the check It depends what is the definition of "valid" in this context. Running "./configure --with-int10" will set "INT10" to "yes". You may choose to ignore this value. I can only guess that current code checked for "yes" as a means to provide a default value when no backend was specified. --with-int10=BACKENDint10 backend: vm86, x86emu or stub > for sys/vm86.h and sys/io.h is not used. Delete it. I agree with ignoring "yes". I don't recall any other module using it in that way. Just be prepared in the case where someone did use it. It's not really dead code, but close enough. The default value is either x86emu or stub for FreeBSD on a PowerPC. Any unrecognized value (such as yes, no or vn86) will not build any int10 backend. No warnings or errors. Hopefully the builder will have some way of finding out why it does not work. The library builds with just the common code. Suggestion: AS_HELP_STRING([--with-int10=BACKEND], [vm86, x86emu or stub (default:auto)]), AC_MSG_ERROR if no valid value is given Verify if there is a need to check for the headers. The code as it is was probably the result of changes around it rather than the intention of the developer. > > Signed-off-by: Jamey Sharp > --- > configure.ac|4 > include/dix-config.h.in |6 -- > 2 files changed, 0 insertions(+), 10 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 93cd6a9..06cf9bf 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -702,10 +702,6 @@ AM_CONDITIONAL(SECURE_RPC, [test "x$SECURE_RPC" = xyes]) > AM_CONDITIONAL(INT10_VM86, [test "x$INT10" = xvm86]) > AM_CONDITIONAL(INT10_X86EMU, [test "x$INT10" = xx86emu]) > AM_CONDITIONAL(INT10_STUB, [test "x$INT10" = xstub]) > -if test "x$INT10" = xyes; then > - dnl VM86 headers > - AC_CHECK_HEADERS([sys/vm86.h sys/io.h]) > -fi > > dnl Handle installing libxf86config > AM_CONDITIONAL(INSTALL_LIBXF86CONFIG, [test "x$INSTALL_LIBXF86CONFIG" = > xyes]) > diff --git a/include/dix-config.h.in b/include/dix-config.h.in > index 4710ef8..5facb11 100644 > --- a/include/dix-config.h.in > +++ b/include/dix-config.h.in > @@ -209,9 +209,6 @@ > */ > #undef HAVE_SYS_DIR_H > > -/* Define to 1 if you have the header file. */ > -#undef HAVE_SYS_IO_H > - > /* Define to 1 if you have the header file, and it defines > `DIR'. > */ > #undef HAVE_SYS_NDIR_H > @@ -225,9 +222,6 @@ > /* Define to 1 if you have the header file. */ > #undef HAVE_SYS_UTSNAME_H > > -/* Define to 1 if you have the header file. */ > -#undef HAVE_SYS_VM86_H > - > /* Define to 1 if you have the header file. */ > #undef HAVE_TSLIB_H > signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Thu, Sep 15, 2011 at 01:30:02PM -0700, Chase Douglas wrote: > Personally, I would prefer a monolithic tree with separate branches for > backporting driver changes to older server versions. I would also prefer > each driver having a stated policy of how many back revisions of servers > are supported by upstream X.org. This would allow the distros to stay on > a given server branch, still receive upstream driver updates, and ensure > there is an understanding of the level of support for each individual > driver. Also, it would keep each branch clean of the server abi #ifdefs > and whatnot, including in back server branches. This is the approach I'd prefer too. Regardless of who does the work needed for backporting, X.Org/fd.o should host the results, and using the server's stable branches as the common location for those backports makes sense to me. Just wanted to throw my vote into the ring... Jamey signature.asc Description: 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: Xserver driver merging pros & cons
On 09/15/2011 02:41 PM, Matt Turner wrote: > On Thu, Sep 15, 2011 at 11:45 AM, Jesse Barnes > wrote: >> Pros: >> 1) easier to propagate API changes across drivers (just like Linux) >> 1a) thus easier to change ABI > > I suppose that's true. How often are we breaking the ABI though? How > often do we break the ABI and it doesn't get fixed in the drivers we > care about within a day or so? It's strange to sort of pretend that we > care about other drivers simply for the point of this argument. This needs an extra sub-point: 1b) thus easier to git-bisect issues The problems enterprise distros may have with merging the drivers back into the server may be offset by this point. I used to work in a much more enterprise-like distro role before I began at Canonical, and I can attest that bisectable sources were a *big* win when a bug was reproducible and the sources could actually be bisected. The current X approach fails the latter condition. -- Chase ___ 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] render: export TriStrip and TriFan to the drivers
On Thu, 15 Sep 2011 14:37:01 -0700, Aaron Plattner wrote: > Reviewed-by: Aaron Plattner > > Thanks for doing this, it was bugging me that we couldn't wrap these > functions at this level. > > Only somewhat related, but what do you think of the idea of creating RENDER > path objects to allow clients to shove entire path descriptions over to the > server for evaluation server-side (possibly on the GPU)? E.g., like > http://www.youtube.com/watch?v=bCrohG6PJQE but happening server-side. Heavily in favour. I watch in horror as people recreate X inside the browser when all that is lacking is the protocol for describing paths and operations upon them. :) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Thu, Sep 15, 2011 at 11:45 AM, Jesse Barnes wrote: > Pros: > 1) easier to propagate API changes across drivers (just like Linux) > 1a) thus easier to change ABI I suppose that's true. How often are we breaking the ABI though? How often do we break the ABI and it doesn't get fixed in the drivers we care about within a day or so? It's strange to sort of pretend that we care about other drivers simply for the point of this argument. I see in other emails that we're not even talking about moving older drivers into the tree, so I'm even a bit more confused. > 2) developers focused on driver development now have more incentive > to make sure the server works well so regular releases can still > happen (i.e. more people working on blockers whether driver or not > as releases approach) In theory. I'm sort of skeptical that suddenly dropping driver code into the X server will incentivize fixing X server blockers enough to actually do it. > 3) allows removal of driver compat code for various server versions > 3a) thus removes combinations of driver+server that developers > have to support & test But, enterprise hates this. It's hard for me to see this as a big win when we know it makes a lot of other people's jobs harder. That, and Keith said at least Intel would keep the ifdef checks in their driver. > 4) increased test coverage for the server as users wanting current > driver code will be building new servers too Maybe. I'd hate to force users to do that just to get new hardware support or a simple driver bug fix. As far as Gentoo goes, this would help the problem of updating the X server and then having your drivers not work. I'm just not sure the benefits are worth the costs though. Matt ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] render: export TriStrip and TriFan to the drivers
Reviewed-by: Aaron Plattner
Thanks for doing this, it was bugging me that we couldn't wrap these
functions at this level.
Only somewhat related, but what do you think of the idea of creating RENDER
path objects to allow clients to shove entire path descriptions over to the
server for evaluation server-side (possibly on the GPU)? E.g., like
http://www.youtube.com/watch?v=bCrohG6PJQE but happening server-side.
On Sun, Sep 04, 2011 at 09:34:08AM -0700, Chris Wilson wrote:
> Rather than perform an intermediate copy and expand the strip and the
> fan into a triangle list (thereby tripling the number of edges that the
> driver needs to process), allow the backend to hook directly into the
> appropriate Composite function.
>
> In order to extend the PictureScreen, without needlessly bumping the
> ABI, we move the existing copy implementations to mipict.c and assign
> those by default. To notify the ddx that the new entry points are
> available, we introduce PICTURE_SCREEN_VERSION.
>
> Signed-off-by: Chris Wilson
> ---
> render/mipict.c | 61
> +++
> render/mipict.h | 20
> render/picture.c| 44 ++--
> render/picturestr.h | 21 +
> 4 files changed, 114 insertions(+), 32 deletions(-)
>
> diff --git a/render/mipict.c b/render/mipict.c
> index 08b2fa7..36128e3 100644
> --- a/render/mipict.c
> +++ b/render/mipict.c
> @@ -573,6 +573,64 @@ miRenderPixelToColor (PictFormatPtr format,
> }
> }
>
> +void
> +miTriStrip (CARD8op,
> + PicturePtr pSrc,
> + PicturePtr pDst,
> + PictFormatPtr maskFormat,
> + INT16 xSrc,
> + INT16 ySrc,
> + int npoints,
> + xPointFixed*points)
> +{
> +xTriangle *tris, *tri;
> +int ntri;
> +
> +ntri = npoints - 2;
> +tris = malloc(ntri * sizeof (xTriangle));
> +if (!tris)
> +return;
> +
> +for (tri = tris; npoints >= 3; npoints--, points++, tri++)
> +{
> +tri->p1 = points[0];
> +tri->p2 = points[1];
> +tri->p3 = points[2];
> +}
> +CompositeTriangles (op, pSrc, pDst, maskFormat, xSrc, ySrc, ntri, tris);
> +free(tris);
> +}
> +
> +void
> +miTriFan (CARD8 op,
> + PicturePtrpSrc,
> + PicturePtrpDst,
> + PictFormatPtr maskFormat,
> + INT16 xSrc,
> + INT16 ySrc,
> + int npoints,
> + xPointFixed *points)
> +{
> +xTriangle*tris, *tri;
> +xPointFixed *first;
> +int ntri;
> +
> +ntri = npoints - 2;
> +tris = malloc(ntri * sizeof (xTriangle));
> +if (!tris)
> + return;
> +
> +first = points++;
> +for (tri = tris; npoints >= 3; npoints--, points++, tri++)
> +{
> + tri->p1 = *first;
> + tri->p2 = points[0];
> + tri->p3 = points[1];
> +}
> +CompositeTriangles (op, pSrc, pDst, maskFormat, xSrc, ySrc, ntri, tris);
> +free(tris);
> +}
> +
> Bool
> miPictureInit (ScreenPtr pScreen, PictFormatPtr formats, int nformats)
> {
> @@ -606,5 +664,8 @@ miPictureInit (ScreenPtr pScreen, PictFormatPtr formats,
> int nformats)
> ps->AddTraps = 0;/* requires DDX support */
> ps->AddTriangles = 0;/* requires DDX support */
>
> +ps->TriStrip = miTriStrip; /* converts call to CompositeTriangles */
> +ps->TriFan = miTriFan;
> +
> return TRUE;
> }
> diff --git a/render/mipict.h b/render/mipict.h
> index f6d9dee..4399a6f 100644
> --- a/render/mipict.h
> +++ b/render/mipict.h
> @@ -140,6 +140,26 @@ miCompositeRects (CARD8 op,
> xRectangle*rects);
>
> extern _X_EXPORT void
> +miTriStrip (CARD8op,
> + PicturePtr pSrc,
> + PicturePtr pDst,
> + PictFormatPtr maskFormat,
> + INT16 xSrc,
> + INT16 ySrc,
> + int npoints,
> + xPointFixed*points);
> +
> +extern _X_EXPORT void
> +miTriFan (CARD8 op,
> + PicturePtrpSrc,
> + PicturePtrpDst,
> + PictFormatPtr maskFormat,
> + INT16 xSrc,
> + INT16 ySrc,
> + int npoints,
> + xPointFixed *points);
> +
> +extern _X_EXPORT void
> miTrapezoidBounds (int ntrap, xTrapezoid *traps, BoxPtr box);
>
> extern _X_EXPORT void
> diff --git a/render/picture.c b/render/picture.c
> index 5640c4d..f134596 100644
> --- a/render/picture.c
> +++ b/render/picture.c
> @@ -1715,23 +1715,14 @@ CompositeTriStrip (CARD8 op,
> int npoints,
> xPointFixed *points)
> {
> -xTriangle *tris, *tri;
> -int ntri;
> -
> +PictureScreenPtr ps = GetPictureScre
Re: Xserver driver merging pros & cons
On Thu, Sep 15, 2011 at 1:17 PM, Keith Packard wrote: > On Thu, 15 Sep 2011 12:34:51 -0400, Alex Deucher > wrote: > >> The number of ABI breaks is minimal (usually 1 per >> xserver) and those can usually be fixed within a day or so of the >> breakage. > > We don't get ABI changes because they're nearly impossible to handle. > >> I don't rebuild the xserver nearly as often as I rebuild >> the ddx so it would mean more work to keep up with the xserver changes >> on a regular basis. > > On the plus side, we'd get a whole lot more coverage of new X server > betas before release... True, but on the other hand, we'd probably get less testing against random older X servers. Alex ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Thu, Sep 15, 2011 at 06:05:46PM +0100, Dave Airlie wrote: > On Thu, Sep 15, 2011 at 5:34 PM, Alex Deucher wrote: > > On Thu, Sep 15, 2011 at 11:45 AM, Jesse Barnes > > wrote: > >> At XDC this week we discussed merging drivers back into the server > >> tree. One thing I found frustrating about the discussion was that we > >> didn't have a whiteboard nor a list of the pros & cons of such a > >> change. So I'd like to capture that here (from memory) to let us > >> continue the discussion about whether it's worth it or not. > >> > >> Luc, I think you're the most vocal opponent of this move, so I've cc'd > >> you so you can enumerate any issues I've forgotten. > >> > >> Anyway, as I recall, the issues are as follows: > >> > >> Pros: > >> 1) easier to propagate API changes across drivers (just like Linux) > >> 1a) thus easier to change ABI > >> 2) developers focused on driver development now have more incentive > >> to make sure the server works well so regular releases can still > >> happen (i.e. more people working on blockers whether driver or not > >> as releases approach) > >> 3) allows removal of driver compat code for various server versions > >> 3a) thus removes combinations of driver+server that developers > >> have to support & test > >> 4) increased test coverage for the server as users wanting current > >> driver code will be building new servers too > >> > >> Cons: > >> 1) more work for distros to backport just driver changes to old > >> servers (especially if people follow through on (3) above) > >> 1a) if backporting is harder, new hardware support will be more > >> difficult to land in "enterprise" level distros > >> 2) harder for users to just upgrade drivers independently, now > >> they'll have to build the whole server > >> 2a) thus less testing of current driver code from technical users > >> > >> I've already made my views pretty clear; I'd prefer merging the drivers > >> back in. But I don't do as much work on the DIX or DDX as I used to, > >> and lots of others would be affected as well, so I'd like to hear what > >> people think. Have I captured the pros & cons fully? What to distro > >> maintainers think? And driver developers, both input & output? > > > > For me personally, I don't seem much advantage in moving the drivers > > into the xserver. The number of ABI breaks is minimal (usually 1 per > > xserver) and those can usually be fixed within a day or so of the > > breakage. I don't rebuild the xserver nearly as often as I rebuild > > the ddx so it would mean more work to keep up with the xserver changes > > on a regular basis. For unmaintained drivers, this might be an > > advantage, but at this point the unmaintained drivers are just about > > all for hardware >10 years old, so I'm not sure how important it is to > > continue to pretend we still support them. > > > > Additionally, as was shown in Jeremy's slides, the number of changes > > in the Xserver has been going down with each successive release. It > > doesn't seem untenable to keep maintained external drivers in sync. > > > > At the moment I have a large project in the works to redo the driver ABI, > its pretty much an impossible project no matter what happens, its a major > ABI change and will pretty much require major reworks off all the drivers. > > Now I've no idea how to do this with the current model, even with the drivers > merged its going to be a real pain to land, thats if I ever even get > it to a useable > stage. That should be the subject of a separate discussion then, to avoid the conflation of the two issues. 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: Xserver driver merging pros & cons
On Sep 15, 2011, at 3:30 PM, Chase Douglas wrote: > On 09/15/2011 01:00 PM, Jeremy Huddleston wrote: >> >> On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote: >> >>> On Thursday 15 of September 2011, Jesse Barnes wrote: At XDC this week we discussed merging drivers back into the server tree. One thing I found frustrating about the discussion was that we didn't have a whiteboard nor a list of the pros & cons of such a change. So I'd like to capture that here (from memory) to let us continue the discussion about whether it's worth it or not. >>> >>> From distro package maintainer point of view I _love_ split drivers. It's >>> so >>> much easier to packages these, rebuild when needed (one faulty, not >>> building, >>> driver doesn't stop whole build process), easier to patch and backport >>> fixes. >> >> I don't see how it is easier. git-cherry-pick should do most of that for >> you just like it currently does. You'd just be doing it in a clone of >> xorg-server rather than a clone of xf86-video-* > > I think this is mixing two issues. Yes, cherry picking individual > commits to get a "newer" driver that still works with an older server is > not terribly difficult. However, you seem to be advocating that the > consumers (distros) should do this. Currently, X.org is doing this by > providing upstream drivers that work against multiple server versions. No, I'm not placing the burden on the distros to do all the work. It's X.org's responsibility to ensure that relevant fixes land in our stable releases. Fixes that add support for new hardware in an unobtrusive way and changes which fix real bugs are great candidates for cherry-picking into the stable branch. If a distro wants something even earlier, they can cherry-pick it themselves, but this is no different than pulling in changes from an unreleased driver currently. Driver maintainers will have their own xorg-server tree living on github, git.fd.o, or whatever, and we'll merge changes from there into xserver. > Maybe you're not really suggesting a shift of maintenance from X.org to > distros. You might be saying that it will be trivial for X.org to > cherry-pick commits and provide multiple upstream driver releases with > latest hardware support for multiple servers. Yes, I think I'm saying the latter. Users and distros have the benefit of knowing that this tarball / tag contains bits that all work together. Distros like Gentoo won't need to do weird version blocking in each ebuild stating which version of the server each driver works on. > However, it does sound > like some want to shift the burden of maintenance. It does shift burden of maintenance onto the xserver stable release manager (currently me) to wrangle driver developers into getting relevant changes into the stable branch. I don't see it as adding to much burden on distros. There will be startup cost associated with updating rpm specs, ebuilds, Portfiles, or whatever you use for package management, but once that is done, the process is pretty much the same. Currently if you find out that the new driver 2.20 doesn't work with server 1.7, what do you do? You figure out how to patch driver 2.20 to work with the old API and submit patches to the driver maintainer. Now, if it turns out that server 1.11.3 doesn't support the new ATI chipset with support that just landed in master, you either wait for 1.11.4 or you pull in the patch yourself. This is the whole purpose for distros, so I don't see it as a real burden. > The maintenance burden and the mechanisms of maintainence can be > completely separated: > > * A monolithic tree with separate branches for backporting new driver > support to older servers > * A monolithic tree with only one branch, but each driver has #defines > and such for supporting different server versions > * Split trees with separate drivers, each tree has separate branches for > backporting new driver support to older servers > * Split trees with separate drivers, but each driver has #defines and > such for supporting different server versions (which is what we have now) > > Each approach then also has its own defined burden of maintenance. Will > X.org provide the commits/patches/branches required to maintain a driver > across server versions? Will distros have to carry this load (even if > the end result lives on freedesktop.org)? Will it vary between drivers? > > I know this is getting farther away from the original topic of > monolithic or separate trees, but the can of worms was opened when one > of the "pros" of monolithic was potentially removing support for older > servers in at least the master branch. Yes, but as others have mentioned, API changes across server versions are currently minor enough that it's easy to fix. This indicates to me that backporting a change from master to an older server would be equally minor. You just cherry-pick the change and fix API changes. M
Re: [PATCH xserver 3/3] devbook.am: maintenance update from docbook.am
On Thu, 2011-09-15 at 13:18 -0500, Jeremy Huddleston wrote: > Ok, then this gets my structural review, but would be nice if someone who > really understands docbook looks at invocation. I would love to as well. However, from a risk management perspective, this new version is mainly a reshuffle of make targets flags. I use an identical copy of docbook.am and devbook.am in the 22 modules having docbook xml. This way we don't have to review 22 differently coded makefiles performing the exact same programming tasks. Thanks > > Reviewed-by: Jeremy Huddleston > > > > On Sep 15, 2011, at 8:41 AM, Gaetan Nadon wrote: > > > On Thu, 2011-09-15 at 02:35 -0500, Jeremy Huddleston wrote: > > > >> On Sep 14, 2011, at 9:12 AM, Gaetan Nadon wrote: > >>> > >>> +if HAVE_XMLTO_TEXT > >>> +noinst_DATA += $(docbook:.xml=.txt) > >>> +%.txt: %.xml $(chapters) > >>> + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< > >>> +endif HAVE_XMLTO_TEXT > >> > >> ^^^ XMLTO_TEXT_FLAGS ?? > >> > >> > > > > Good observation. The txt format is obtained by first transforming xml > > to html using the same xsltproc and stylesheet. Then it is converted to > > text using one of the three tools w3m, lynks or links. Although > > confusing, it is more accurate to use the same html flags. It also looks > > strange to have olink flags when you cannot have cross-reference > > documents between text file. > > > > So this one is good, there were no lack of opportunities for errors. > > > > Thanks > > ___ > > 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 > signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
Le 15/09/2011 17:45, Jesse Barnes a écrit : At XDC this week we discussed merging drivers back into the server tree. One thing I found frustrating about the discussion was that we didn't have a whiteboard nor a list of the pros& cons of such a change. So I'd like to capture that here (from memory) to let us continue the discussion about whether it's worth it or not. With my (dusty) Gentoo hat on, our needs as a source distro are quite simple: if we could influence any decision, we'd like to be able to build the server and drivers separately. In other words, a user installing (and therefor *building*) a new driver shouldn't have to rebuild the server and all the driver s/he has already installed. That being said, a server with merged drivers would still be an order of magnitude faster to build than the old XFree86 monolith (no docs, no libs, no static swrast, etc). Speaking of mesa, the drivers are all already merged and none of our users have ever complained about that... If those who actually work on the code base feel merging things would help them rock Xorg even further, I guess I'll do my best to support them in Gentoo. Cheers, Rémi ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On 09/15/2011 01:00 PM, Jeremy Huddleston wrote: > > On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote: > >> On Thursday 15 of September 2011, Jesse Barnes wrote: >>> At XDC this week we discussed merging drivers back into the server >>> tree. One thing I found frustrating about the discussion was that we >>> didn't have a whiteboard nor a list of the pros & cons of such a >>> change. So I'd like to capture that here (from memory) to let us >>> continue the discussion about whether it's worth it or not. >> >> From distro package maintainer point of view I _love_ split drivers. It's so >> much easier to packages these, rebuild when needed (one faulty, not >> building, >> driver doesn't stop whole build process), easier to patch and backport fixes. > > I don't see how it is easier. git-cherry-pick should do most of that for you > just like it currently does. You'd just be doing it in a clone of > xorg-server rather than a clone of xf86-video-* I think this is mixing two issues. Yes, cherry picking individual commits to get a "newer" driver that still works with an older server is not terribly difficult. However, you seem to be advocating that the consumers (distros) should do this. Currently, X.org is doing this by providing upstream drivers that work against multiple server versions. Maybe you're not really suggesting a shift of maintenance from X.org to distros. You might be saying that it will be trivial for X.org to cherry-pick commits and provide multiple upstream driver releases with latest hardware support for multiple servers. However, it does sound like some want to shift the burden of maintenance. The maintenance burden and the mechanisms of maintainence can be completely separated: * A monolithic tree with separate branches for backporting new driver support to older servers * A monolithic tree with only one branch, but each driver has #defines and such for supporting different server versions * Split trees with separate drivers, each tree has separate branches for backporting new driver support to older servers * Split trees with separate drivers, but each driver has #defines and such for supporting different server versions (which is what we have now) Each approach then also has its own defined burden of maintenance. Will X.org provide the commits/patches/branches required to maintain a driver across server versions? Will distros have to carry this load (even if the end result lives on freedesktop.org)? Will it vary between drivers? I know this is getting farther away from the original topic of monolithic or separate trees, but the can of worms was opened when one of the "pros" of monolithic was potentially removing support for older servers in at least the master branch. Personally, I would prefer a monolithic tree with separate branches for backporting driver changes to older server versions. I would also prefer each driver having a stated policy of how many back revisions of servers are supported by upstream X.org. This would allow the distros to stay on a given server branch, still receive upstream driver updates, and ensure there is an understanding of the level of support for each individual driver. Also, it would keep each branch clean of the server abi #ifdefs and whatnot, including in back server branches. Note that I'm speaking here with my personal developer hat on. Bryce Harrington and Chris Halse Rogers would be better to chime in on Canonical support for Ubuntu, but I imagine that it really doesn't matter too much to us because we tend to stay near the bleeding edge. -- Chase ___ 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 rendercheck] t_tsrccoords: Skip this test when using indexed picture formats
This test would fail at, for example, depth 8 because indexed color
comparisons are not implemented in rendercheck yet. This commit
workarounds this by passing the test if indexed picture formats are
used.
Signed-off-by: Damien Leone
Reviewed-by: Aaron Plattner
---
t_tsrccoords.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t_tsrccoords.c b/t_tsrccoords.c
index 279591d..355880a 100644
--- a/t_tsrccoords.c
+++ b/t_tsrccoords.c
@@ -89,6 +89,14 @@ trans_coords_test(Display *dpy, picture_info *win,
picture_info *white,
XImage *image;
int x, y;
+ /* Skip this test when using indexed picture formats because
+* indexed color comparisons are not implemented in rendercheck
+* yet.
+*/
+ if (win->format->type == PictTypeIndexed) {
+ return TRUE;
+ }
+
src = create_dot_picture(dpy);
if (src == NULL) {
fprintf(stderr, "couldn't allocate picture for test\n");
--
1.7.5.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Thursday 15 of September 2011, Jeremy Huddleston wrote: > On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote: > > On Thursday 15 of September 2011, Jesse Barnes wrote: > >> At XDC this week we discussed merging drivers back into the server > >> tree. One thing I found frustrating about the discussion was that we > >> didn't have a whiteboard nor a list of the pros & cons of such a > >> change. So I'd like to capture that here (from memory) to let us > >> continue the discussion about whether it's worth it or not. > > > > From distro package maintainer point of view I _love_ split drivers. It's > > so much easier to packages these, rebuild when needed (one faulty, not > > building, driver doesn't stop whole build process), easier to patch and > > backport fixes. > > I don't see how it is easier. git-cherry-pick should do most of that for > you just like it currently does. You'd just be doing it in a clone of > xorg-server rather than a clone of xf86-video-* + rebuilding + testing applies to "backporting". rebuilding which ends with rpm packaging of course. > > Monolitic thing causes one build problem to stop building the whole > > thing. > > Hopefully integration will help find such build failures BEFORE they're > pushed. It also makes failure points more obvious on the tinderbox. The problematic failures are mainly due to different non X related environment (like new gcc, libtool or something). > > Also with monolitic you need to find out which files are for which > > package (in case if you want to split that into subpackages on rpm spec > > level for example). > > I don't think that's a particularly persuasive argument. Mask out > /usr/lib/xorg/modules/drivers and /usr/lib/xorg/modules/input from > installing with your master xorg-server package. Each driver in each of > those directories gets their own subpackage. When new ones show up, > they'll be excluded by your base exclusion rule until you create a new > package. There are manual pages, docs, sometimes utils, too. This isn't some great problem but it is still easier with non-monolitic way. -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 8/8] Remove unused vtSysreq
It looks to me like you should also delete VTSYSRQ from
hw/xfree86/parser/xf86tokens.h.
If you fix that,
Reviewed-by: Jamey Sharp
I can't review the remaining patches in this series because I'm not
familiar enough with the BSDs.
Jamey
On Thu, Sep 15, 2011 at 11:20:28PM +0600, Alexandr Shadchin wrote:
> Signed-off-by: Alexandr Shadchin
> ---
> hw/xfree86/common/xf86Config.c | 13 -
> hw/xfree86/common/xf86Globals.c|1 -
> hw/xfree86/common/xf86Privstr.h|1 -
> hw/xfree86/man/xorg.conf.man | 12
> hw/xfree86/os-support/xf86_OSlib.h | 10 --
> 5 files changed, 0 insertions(+), 37 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
> index 58b30dd..5b8c2cd 100644
> --- a/hw/xfree86/common/xf86Config.c
> +++ b/hw/xfree86/common/xf86Config.c
> @@ -670,7 +670,6 @@ typedef enum {
> FLAG_DISABLEVIDMODE,
> FLAG_ALLOWNONLOCAL,
> FLAG_ALLOWMOUSEOPENFAIL,
> -FLAG_VTSYSREQ,
> FLAG_SAVER_BLANKTIME,
> FLAG_DPMS_STANDBYTIME,
> FLAG_DPMS_SUSPENDTIME,
> @@ -712,8 +711,6 @@ static OptionInfoRec FlagOptions[] = {
> {0}, FALSE },
>{ FLAG_ALLOWMOUSEOPENFAIL, "AllowMouseOpenFail", OPTV_BOOLEAN,
> {0}, FALSE },
> - { FLAG_VTSYSREQ, "VTSysReq", OPTV_BOOLEAN,
> - {0}, FALSE },
>{ FLAG_SAVER_BLANKTIME,"BlankTime" , OPTV_INTEGER,
> {0}, FALSE },
>{ FLAG_DPMS_STANDBYTIME, "StandbyTime", OPTV_INTEGER,
> @@ -868,16 +865,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
> XF86OptionPtr layoutopts)
> if (xf86GetOptValBool(FlagOptions, FLAG_ALLOWMOUSEOPENFAIL, &value))
> xf86Info.allowMouseOpenFail = value;
>
> -if (xf86GetOptValBool(FlagOptions, FLAG_VTSYSREQ, &value)) {
> -#ifdef USE_VT_SYSREQ
> - xf86Info.vtSysreq = value;
> - xf86Msg(X_CONFIG, "VTSysReq %s\n", value ? "enabled" : "disabled");
> -#else
> - if (value)
> - xf86Msg(X_WARNING, "VTSysReq is not supported on this OS\n");
> -#endif
> -}
> -
> xf86Info.pmFlag = TRUE;
> if (xf86GetOptValBool(FlagOptions, FLAG_NOPM, &value))
> xf86Info.pmFlag = !value;
> diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
> index 5e56438..182b0cc 100644
> --- a/hw/xfree86/common/xf86Globals.c
> +++ b/hw/xfree86/common/xf86Globals.c
> @@ -96,7 +96,6 @@ InputInfoPtr xf86InputDevs = NULL;
> xf86InfoRec xf86Info = {
> .consoleFd = -1,
> .vtno = -1,
> -.vtSysreq = FALSE,
> .lastEventTime = -1,
> .vtRequestsPending = FALSE,
> #ifdef sun
> diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/xf86Privstr.h
> index added3c..0a08a7b 100644
> --- a/hw/xfree86/common/xf86Privstr.h
> +++ b/hw/xfree86/common/xf86Privstr.h
> @@ -57,7 +57,6 @@ typedef enum {
> typedef struct {
> int consoleFd;
> int vtno;
> -Bool vtSysreq;
>
> /* event handler part */
> int lastEventTime;
> diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man
> index f406f82..17579ee 100644
> --- a/hw/xfree86/man/xorg.conf.man
> +++ b/hw/xfree86/man/xorg.conf.man
> @@ -560,18 +560,6 @@ drivers to not report failure if the mouse device can't
> be opened/initialised.
> It has no effect on the evdev(__drivermansuffix__) or other drivers.
> Default: false.
> .TP 7
> -.BI "Option \*qVTSysReq\*q \*q" boolean \*q
> -enables the SYSV\-style VT switch sequence for non\-SYSV systems
> -which support VT switching.
> -This sequence is
> -.B Alt\-SysRq
> -followed by a function key
> -.RB ( Fn ).
> -This prevents the __xservername__ server trapping the
> -keys used for the default VT switch sequence, which means that clients can
> -access them.
> -Default: off.
> -.TP 7
> .BI "Option \*qBlankTime\*q \*q" time \*q
> sets the inactivity timeout for the
> .B blank
> diff --git a/hw/xfree86/os-support/xf86_OSlib.h
> b/hw/xfree86/os-support/xf86_OSlib.h
> index fddde8a..1d59060 100644
> --- a/hw/xfree86/os-support/xf86_OSlib.h
> +++ b/hw/xfree86/os-support/xf86_OSlib.h
> @@ -168,11 +168,6 @@
> # define POSIX_TTY
> # endif /* SVR4 */
>
> -
> -# if defined(sun) && defined(HAS_USL_VTS)
> -# define USE_VT_SYSREQ
> -# endif
> -
> #endif /* (SYSV || SVR4) */
>
> /**/
> @@ -207,7 +202,6 @@
> # define LDSMAP PIO_SCRNMAP
> # define LDNMAP LDSMAP
> # define CLEARDTR_SUPPORT
> -# define USE_VT_SYSREQ
> # endif
>
> # define POSIX_TTY
> @@ -343,10 +337,6 @@
>
> # define CLEARDTR_SUPPORT
>
> -# if defined(SYSCONS_SUPPORT) || defined(PCVT_SUPPORT) ||
> defined(WSCONS_SUPPORT)
> -# define USE_VT_SYSREQ
> -# endif
> -
> #endif
> /* __FreeBSD_kernel__ || __NetBSD__ || __OpenBSD__ || __bsdi__
Re: [PATCH xserver 1/8] bsd: Remove unused macros KBD_FD
I review this in the sense that the comments match the src changes and look
well formed. Hopefully another BSD developer can vouch for whether they
actually "do the right thing" rather than just "do the stated thing"
Reviewed-by: Jeremy Huddleston
On Sep 15, 2011, at 12:20 PM, Alexandr Shadchin wrote:
> Signed-off-by: Alexandr Shadchin
> ---
> hw/xfree86/os-support/bsd/bsd_bell.c |4
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/hw/xfree86/os-support/bsd/bsd_bell.c
> b/hw/xfree86/os-support/bsd/bsd_bell.c
> index 55eb752..fb457db 100644
> --- a/hw/xfree86/os-support/bsd/bsd_bell.c
> +++ b/hw/xfree86/os-support/bsd/bsd_bell.c
> @@ -37,10 +37,6 @@
> #include "xf86Priv.h"
> #include "xf86_OSlib.h"
>
> -#ifdef WSCONS_SUPPORT
> -#define KBD_FD(i) ((i).kbdFd != -1 ? (i).kbdFd : (i).consoleFd)
> -#endif
> -
> void
> xf86OSRingBell(int loudness, int pitch, int duration)
> {
> --
> 1.7.6
>
> ___
> 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
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Sep 15, 2011, at 2:45 PM, Arkadiusz Miśkiewicz wrote: > On Thursday 15 of September 2011, Jesse Barnes wrote: >> At XDC this week we discussed merging drivers back into the server >> tree. One thing I found frustrating about the discussion was that we >> didn't have a whiteboard nor a list of the pros & cons of such a >> change. So I'd like to capture that here (from memory) to let us >> continue the discussion about whether it's worth it or not. > > From distro package maintainer point of view I _love_ split drivers. It's so > much easier to packages these, rebuild when needed (one faulty, not building, > driver doesn't stop whole build process), easier to patch and backport fixes. I don't see how it is easier. git-cherry-pick should do most of that for you just like it currently does. You'd just be doing it in a clone of xorg-server rather than a clone of xf86-video-* > Monolitic thing causes one build problem to stop building the whole thing. Hopefully integration will help find such build failures BEFORE they're pushed. It also makes failure points more obvious on the tinderbox. > Also with monolitic you need to find out which files are for which package > (in > case if you want to split that into subpackages on rpm spec level for > example). I don't think that's a particularly persuasive argument. Mask out /usr/lib/xorg/modules/drivers and /usr/lib/xorg/modules/input from installing with your master xorg-server package. Each driver in each of those directories gets their own subpackage. When new ones show up, they'll be excluded by your base exclusion rule until you create a new package. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 4/8] bsd: Remove dead code
It wasn't immediately obvious to me that the comment ("stdin is already
closed, so this won't work") was actually true. I've confirmed that the
other comment is true ("stdin is already closed in OsInit()"), so I
believe this patch is correct. I'd like to see some explanation in the
commit message, though; something like:
Since OsInit closes stdin before the xfree86 DDX opens the
console, fstat on stdin will always fail, so it's safe to delete
code that attempts it.
I'd also like a better short description than "Remove dead code".
Still:
Reviewed-by: Jamey Sharp
On Thu, Sep 15, 2011 at 11:20:24PM +0600, Alexandr Shadchin wrote:
> Signed-off-by: Alexandr Shadchin
> ---
> hw/xfree86/os-support/bsd/bsd_init.c | 23 ---
> 1 files changed, 0 insertions(+), 23 deletions(-)
>
> diff --git a/hw/xfree86/os-support/bsd/bsd_init.c
> b/hw/xfree86/os-support/bsd/bsd_init.c
> index 84c6b3d..1825672 100644
> --- a/hw/xfree86/os-support/bsd/bsd_init.c
> +++ b/hw/xfree86/os-support/bsd/bsd_init.c
> @@ -211,9 +211,6 @@ xf86OpenConsole()
> "%s: No console driver found\n\tSupported drivers: %s\n\t%s",
> "xf86OpenConsole", cons_drivers, CHECK_DRIVER_MSG);
> }
> -#if 0 /* stdin is already closed in OsInit() */
> - fclose(stdin);
> -#endif
> xf86Info.consoleFd = fd;
>
> switch (xf86Info.consType)
> @@ -372,7 +369,6 @@ xf86OpenSyscons()
> int fd = -1;
> vtmode_t vtmode;
> char vtname[12];
> -struct stat status;
> long syscons_version;
> MessageType from;
>
> @@ -425,20 +421,11 @@ xf86OpenSyscons()
> {
> /*
>* All VTs are in use. If initialVT was found, use it.
> - * Otherwise, if stdin is a VT, use that one.
> - * XXX stdin is already closed, so this won't work.
>*/
> if (initialVT != -1)
> {
> xf86Info.vtno = initialVT;
> }
> - else if ((fstat(0, &status) >= 0)
> - && S_ISCHR(status.st_mode)
> - && (ioctl(0, VT_GETMODE, &vtmode) >= 0))
> - {
> - /* stdin is a VT */
> - xf86Info.vtno = minor(status.st_rdev) + 1;
> - }
> else
> {
> if (syscons_version >= 0x100)
> @@ -508,7 +495,6 @@ xf86OpenPcvt()
> int fd = -1;
> vtmode_t vtmode;
> char vtname[12], *vtprefix;
> -struct stat status;
> struct pcvtid pcvt_version;
>
> #ifndef __OpenBSD__
> @@ -554,20 +540,11 @@ xf86OpenPcvt()
> {
> /*
>* All VTs are in use. If initialVT was found, use it.
> - * Otherwise, if stdin is a VT, use that one.
> - * XXX stdin is already closed, so this won't work.
>*/
> if (initialVT != -1)
> {
> xf86Info.vtno = initialVT;
> }
> - else if ((fstat(0, &status) >= 0)
> - && S_ISCHR(status.st_mode)
> - && (ioctl(0, VT_GETMODE, &vtmode) >= 0))
> - {
> - /* stdin is a VT */
> - xf86Info.vtno = minor(status.st_rdev) + 1;
> - }
> else
> {
> FatalError("%s: Cannot find a free VT",
> --
> 1.7.6
>
> ___
> 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
signature.asc
Description: 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: Xserver driver merging pros & cons
On Thursday 15 of September 2011, Jesse Barnes wrote: > At XDC this week we discussed merging drivers back into the server > tree. One thing I found frustrating about the discussion was that we > didn't have a whiteboard nor a list of the pros & cons of such a > change. So I'd like to capture that here (from memory) to let us > continue the discussion about whether it's worth it or not. From distro package maintainer point of view I _love_ split drivers. It's so much easier to packages these, rebuild when needed (one faulty, not building, driver doesn't stop whole build process), easier to patch and backport fixes. Monolitic thing causes one build problem to stop building the whole thing. Also with monolitic you need to find out which files are for which package (in case if you want to split that into subpackages on rpm spec level for example). -- Arkadiusz MiśkiewiczPLD/Linux Team arekm / maven.plhttp://ftp.pld-linux.org/ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 3/8] bsd: Variable devConsoleFd need only if defined PCCONS_SUPPORT
Again, based purely on code inspection, this looks right. Reviewed-by: Jamey Sharp On Thu, Sep 15, 2011 at 11:20:23PM +0600, Alexandr Shadchin wrote: > Signed-off-by: Alexandr Shadchin > --- > hw/xfree86/os-support/bsd/bsd_init.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/hw/xfree86/os-support/bsd/bsd_init.c > b/hw/xfree86/os-support/bsd/bsd_init.c > index e5c8495..84c6b3d 100644 > --- a/hw/xfree86/os-support/bsd/bsd_init.c > +++ b/hw/xfree86/os-support/bsd/bsd_init.c > @@ -41,7 +41,10 @@ > #include > > static Bool KeepTty = FALSE; > + > +#ifdef PCCONS_SUPPORT > static int devConsoleFd = -1; > +#endif > #if defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT) > static int VTnum = -1; > static int initialVT = -1; > @@ -694,8 +697,10 @@ xf86CloseConsole() > } > > close(xf86Info.consoleFd); > +#ifdef PCCONS_SUPPORT > if (devConsoleFd >= 0) > close(devConsoleFd); > +#endif > return; > } > > -- > 1.7.6 > > ___ > 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 signature.asc Description: 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 xserver 2/8] bsd: Replacement screenFd on consoleFd because they are equivalent
Based purely on code inspection, this patch looks right to me.
Reviewed-by: Jamey Sharp
On Thu, Sep 15, 2011 at 11:20:22PM +0600, Alexandr Shadchin wrote:
> Signed-off-by: Alexandr Shadchin
> ---
> hw/xfree86/common/xf86Globals.c |1 -
> hw/xfree86/common/xf86Privstr.h |2 --
> hw/xfree86/os-support/bsd/alpha_video.c |2 +-
> hw/xfree86/os-support/bsd/arm_video.c |6 +++---
> hw/xfree86/os-support/bsd/bsd_init.c | 13 +
> hw/xfree86/os-support/bsd/i386_video.c|2 +-
> hw/xfree86/os-support/bsd/ppc_video.c |4 ++--
> hw/xfree86/os-support/bsd/sparc64_video.c |2 +-
> 8 files changed, 9 insertions(+), 23 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
> index 16d5557..5e56438 100644
> --- a/hw/xfree86/common/xf86Globals.c
> +++ b/hw/xfree86/common/xf86Globals.c
> @@ -109,7 +109,6 @@ xf86InfoRec xf86Info = {
> .caughtSignal = FALSE,
> .currentScreen = NULL,
> #ifdef CSRG_BASED
> -.screenFd = -1,
> .consType = -1,
> #endif
> .allowMouseOpenFail = FALSE,
> diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/xf86Privstr.h
> index 608f9bd..added3c 100644
> --- a/hw/xfree86/common/xf86Privstr.h
> +++ b/hw/xfree86/common/xf86Privstr.h
> @@ -74,8 +74,6 @@ typedef struct {
> /* graphics part */
> ScreenPtrcurrentScreen;
> #if defined(CSRG_BASED) || defined(__FreeBSD_kernel__)
> -int screenFd; /* fd for memory mapped access
> to
> - * vga card */
> int consType; /* Which console driver? */
> #endif
>
> diff --git a/hw/xfree86/os-support/bsd/alpha_video.c
> b/hw/xfree86/os-support/bsd/alpha_video.c
> index bb3a5cb..15eb2a4 100644
> --- a/hw/xfree86/os-support/bsd/alpha_video.c
> +++ b/hw/xfree86/os-support/bsd/alpha_video.c
> @@ -340,7 +340,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned
> long Size, int flags)
> base = mmap(0, Size,
> (flags & VIDMEM_READONLY) ?
>PROT_READ : (PROT_READ | PROT_WRITE),
> - MAP_FLAGS, xf86Info.screenFd,
> + MAP_FLAGS, xf86Info.consoleFd,
> (unsigned long)Base + BUS_BASE);
> if (base == MAP_FAILED)
> {
> diff --git a/hw/xfree86/os-support/bsd/arm_video.c
> b/hw/xfree86/os-support/bsd/arm_video.c
> index 482d53f..eb631a7 100644
> --- a/hw/xfree86/os-support/bsd/arm_video.c
> +++ b/hw/xfree86/os-support/bsd/arm_video.c
> @@ -213,7 +213,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned
> long Size, int flags)
> base = mmap(0, Size,
> (flags & VIDMEM_READONLY) ?
>PROT_READ : (PROT_READ | PROT_WRITE),
> - MAP_FLAGS, xf86Info.screenFd,
> + MAP_FLAGS, xf86Info.consoleFd,
> (unsigned long)Base - 0xA);
> if (base == MAP_FAILED)
> {
> @@ -306,7 +306,7 @@ checkMapInfo(Bool warn, int Region)
>
> if(!memAccP->Checked)
> {
> - if(ioctl(xf86Info.screenFd, memAccP->ioctl, &(memAccP->memInfo)) == -1)
> + if(ioctl(xf86Info.consoleFd, memAccP->ioctl, &(memAccP->memInfo)) == -1)
> {
> if(warn)
> {
> @@ -360,7 +360,7 @@ xf86MapInfoMap(struct memAccess *memInfoP, pointer Base,
> unsigned long Size)
>Size,
>PROT_READ | PROT_WRITE,
>MAP_SHARED,
> - xf86Info.screenFd,
> + xf86Info.consoleFd,
>(unsigned long)mapInfoP->u.map_info_mmap.map_offset))
> == (pointer)-1)
> {
> diff --git a/hw/xfree86/os-support/bsd/bsd_init.c
> b/hw/xfree86/os-support/bsd/bsd_init.c
> index 123eb17..e5c8495 100644
> --- a/hw/xfree86/os-support/bsd/bsd_init.c
> +++ b/hw/xfree86/os-support/bsd/bsd_init.c
> @@ -212,7 +212,6 @@ xf86OpenConsole()
> fclose(stdin);
> #endif
> xf86Info.consoleFd = fd;
> - xf86Info.screenFd = fd;
>
> switch (xf86Info.consType)
> {
> @@ -688,22 +687,12 @@ xf86CloseConsole()
> case WSCONS:
>{
> int mode = WSDISPLAYIO_MODE_EMUL;
> - ioctl(xf86Info.screenFd, WSDISPLAYIO_SMODE, &mode);
> + ioctl(xf86Info.consoleFd, WSDISPLAYIO_SMODE, &mode);
> break;
>}
> #endif
> }
>
> -if (xf86Info.screenFd != xf86Info.consoleFd)
> -{
> - close(xf86Info.screenFd);
> - close(xf86Info.consoleFd);
> - if ((xf86Info.consoleFd = open("/dev/console",O_RDONLY,0)) <0)
> - {
> - xf86FatalError("xf86CloseConsole: Cannot open /dev/console (%s)",
> -strerror(errno));
> - }
> -}
> close(xf86Info.consoleFd);
> if (devConsoleFd >= 0)
> close(devConsoleFd);
> dif
Re: [PATCH xserver 1/8] bsd: Remove unused macros KBD_FD
Reviewed-by: Jamey Sharp
On Thu, Sep 15, 2011 at 11:20:21PM +0600, Alexandr Shadchin wrote:
> Signed-off-by: Alexandr Shadchin
> ---
> hw/xfree86/os-support/bsd/bsd_bell.c |4
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/hw/xfree86/os-support/bsd/bsd_bell.c
> b/hw/xfree86/os-support/bsd/bsd_bell.c
> index 55eb752..fb457db 100644
> --- a/hw/xfree86/os-support/bsd/bsd_bell.c
> +++ b/hw/xfree86/os-support/bsd/bsd_bell.c
> @@ -37,10 +37,6 @@
> #include "xf86Priv.h"
> #include "xf86_OSlib.h"
>
> -#ifdef WSCONS_SUPPORT
> -#define KBD_FD(i) ((i).kbdFd != -1 ? (i).kbdFd : (i).consoleFd)
> -#endif
> -
> void
> xf86OSRingBell(int loudness, int pitch, int duration)
> {
> --
> 1.7.6
>
> ___
> 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
signature.asc
Description: 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: Xserver driver merging pros & cons
>> 3) Out of tree drivers will become second class citizens. > > I don't see that as a con. I see that as a benefit. If something is not in > the tree, it IS a second class citizen, and users should not expect it to > work any more. If the trident driver breaks, they can always use vesa. > >> This doesn't >> apply to proprietary drivers only but also e.g. to the Gallium xorg >> state tracker, which we may want to use for Radeons at some point (and >> some nouveau people have been playing with it as well, but I don't know >> what their plans are for it). > > As someone without much experience with the Gallium xorg state tracker, I'm > curious what technical hurdles prevent you from using it as a library linked > against by the x11 driver. I thought Thomas wanted to move the gallium state tracker to a driver/xa split anyways going forward. > >> Speaking as a radeon driver developer, merging the driver into the >> server tree would be unworkable at this point because since the "new >> development model" has been in effect, it's not possible to get even >> trivial changes into the server tree without a ridiculous amount of >> time/effort. > > Can you be more specific? When we were discussing this yesterday, it seemed > like the "new development model" was working and that it was no longer a > barrier to this problem. The longest you will go to get in to a stable > release is 7 weeks. That is in the rare case that you have it ready > immediately after the release of rc2 and you really want to use a stable > release version. > > Instead of pushing your changes to xf86-video-ati, you would push them to > xorg-server-ati and when ready send [PULL] emails to the manager for the > branch you want your changes to land in. > > Looking at the xf86-video-ati git repo, I was shocked to see that you really > only have master and don't use separate branches for old stable releases. > IMO, transitioning to a code management paradigm of development versus stable > branches would be a win for you and your customers because you can do more > experimental changes in master and just cherry pick support for new hardware > and general bug fixes into the stable branch. We do, its just not much interesting happened lately. We only branch stable when we see the need. Dave. ___ 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 fonts-util 2/2] If cross-compiling, we don't have to run mkfontdir
On Sep 15, 2011, at 11:06 AM, Jon TURNEY wrote:
> On 14/09/2011 00:09, Jeremy Huddleston wrote:
>> This is confusing to me. Why do you add the extra " ; echo '** mkfontdir'"?
>
>> On Sep 12, 2011, at 9:18 AM, Jon TURNEY wrote:
>>> +AC_DEFUN([XORG_FONT_MKFONTDIR],[
>>> + if test x"$cross_compiling" != x"no" ; then
>>> + AC_PATH_PROG(MKFONTDIR, mkfontdir, "")
>>> + MKFONTDIR_WARN='echo "** Warning: mkfontdir not run" ; echo "**
>>> Run mkfontdir manually on host system"'
>>> +
>>> + if test x"$MKFONTDIR" = x; then
>>> + MKFONTDIR="${MKFONTDIR_WARN} ; echo '** mkfontdir'"
>>> + fi
>>> + else
>>> + XORG_FONT_REQUIRED_PROG(MKFONTDIR, mkfontdir)
>>> + fi
>>> +
>>> + AC_SUBST([MKFONTDIR])
>>> +])
>
> MKFONTDIR_WARN is the command to emit the warning that mkfontdir could be
> run, MKFONTDIR is the actual command which will be used in the makefile, and
> is supplied with a directory path, so we need to consume that, and do so by
> outputting the command we would have run if mkfontdir was available
Ah. I see. Clever.
> Hope that clears things up for you :-)
>
> It looks like this suffers a bit from being patterned after the
> XORG_FONT_FCCACHE macro a few lines above. This is perhaps wrong, as unlike
> XORG_FONT_FCCACHE, the warning is only used in one place.
Reviewed-by: Jeremy Huddleston
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Sep 15, 2011, at 11:02 AM, Michel Dänzer wrote: > 3) Out of tree drivers will become second class citizens. I don't see that as a con. I see that as a benefit. If something is not in the tree, it IS a second class citizen, and users should not expect it to work any more. If the trident driver breaks, they can always use vesa. > This doesn't > apply to proprietary drivers only but also e.g. to the Gallium xorg > state tracker, which we may want to use for Radeons at some point (and > some nouveau people have been playing with it as well, but I don't know > what their plans are for it). As someone without much experience with the Gallium xorg state tracker, I'm curious what technical hurdles prevent you from using it as a library linked against by the x11 driver. > Speaking as a radeon driver developer, merging the driver into the > server tree would be unworkable at this point because since the "new > development model" has been in effect, it's not possible to get even > trivial changes into the server tree without a ridiculous amount of > time/effort. Can you be more specific? When we were discussing this yesterday, it seemed like the "new development model" was working and that it was no longer a barrier to this problem. The longest you will go to get in to a stable release is 7 weeks. That is in the rare case that you have it ready immediately after the release of rc2 and you really want to use a stable release version. Instead of pushing your changes to xf86-video-ati, you would push them to xorg-server-ati and when ready send [PULL] emails to the manager for the branch you want your changes to land in. Looking at the xf86-video-ati git repo, I was shocked to see that you really only have master and don't use separate branches for old stable releases. IMO, transitioning to a code management paradigm of development versus stable branches would be a win for you and your customers because you can do more experimental changes in master and just cherry pick support for new hardware and general bug fixes into the stable branch. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Sep 15, 2011, at 11:34 AM, Alex Deucher wrote: > For me personally, I don't seem much advantage in moving the drivers > into the xserver. The number of ABI breaks is minimal (usually 1 per > xserver) and those can usually be fixed within a day or so of the > breakage. I don't rebuild the xserver nearly as often as I rebuild > the ddx so it would mean more work to keep up with the xserver changes > on a regular basis. For unmaintained drivers, this might be an > advantage, but at this point the unmaintained drivers are just about > all for hardware >10 years old, so I'm not sure how important it is to > continue to pretend we still support them. Unmaintained drivers would be left out of tree. Ideally, we would just bring in the 5 or so video drivers that are used and maintained and the handful of input drivers that are still used. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 3/3] devbook.am: maintenance update from docbook.am
Ok, then this gets my structural review, but would be nice if someone who really understands docbook looks at invocation. Reviewed-by: Jeremy Huddleston On Sep 15, 2011, at 8:41 AM, Gaetan Nadon wrote: > On Thu, 2011-09-15 at 02:35 -0500, Jeremy Huddleston wrote: > >> On Sep 14, 2011, at 9:12 AM, Gaetan Nadon wrote: >>> >>> +if HAVE_XMLTO_TEXT >>> +noinst_DATA += $(docbook:.xml=.txt) >>> +%.txt: %.xml $(chapters) >>> + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< >>> +endif HAVE_XMLTO_TEXT >> >> ^^^ XMLTO_TEXT_FLAGS ?? >> >> > > Good observation. The txt format is obtained by first transforming xml > to html using the same xsltproc and stylesheet. Then it is converted to > text using one of the three tools w3m, lynks or links. Although > confusing, it is more accurate to use the same html flags. It also looks > strange to have olink flags when you cannot have cross-reference > documents between text file. > > So this one is good, there were no lack of opportunities for errors. > > Thanks > ___ > 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 xserver 8/8] Remove unused vtSysreq
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/common/xf86Config.c | 13 -
hw/xfree86/common/xf86Globals.c|1 -
hw/xfree86/common/xf86Privstr.h|1 -
hw/xfree86/man/xorg.conf.man | 12
hw/xfree86/os-support/xf86_OSlib.h | 10 --
5 files changed, 0 insertions(+), 37 deletions(-)
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 58b30dd..5b8c2cd 100644
--- a/hw/xfree86/common/xf86Config.c
+++ b/hw/xfree86/common/xf86Config.c
@@ -670,7 +670,6 @@ typedef enum {
FLAG_DISABLEVIDMODE,
FLAG_ALLOWNONLOCAL,
FLAG_ALLOWMOUSEOPENFAIL,
-FLAG_VTSYSREQ,
FLAG_SAVER_BLANKTIME,
FLAG_DPMS_STANDBYTIME,
FLAG_DPMS_SUSPENDTIME,
@@ -712,8 +711,6 @@ static OptionInfoRec FlagOptions[] = {
{0}, FALSE },
{ FLAG_ALLOWMOUSEOPENFAIL, "AllowMouseOpenFail", OPTV_BOOLEAN,
{0}, FALSE },
- { FLAG_VTSYSREQ, "VTSysReq", OPTV_BOOLEAN,
- {0}, FALSE },
{ FLAG_SAVER_BLANKTIME, "BlankTime" , OPTV_INTEGER,
{0}, FALSE },
{ FLAG_DPMS_STANDBYTIME, "StandbyTime", OPTV_INTEGER,
@@ -868,16 +865,6 @@ configServerFlags(XF86ConfFlagsPtr flagsconf,
XF86OptionPtr layoutopts)
if (xf86GetOptValBool(FlagOptions, FLAG_ALLOWMOUSEOPENFAIL, &value))
xf86Info.allowMouseOpenFail = value;
-if (xf86GetOptValBool(FlagOptions, FLAG_VTSYSREQ, &value)) {
-#ifdef USE_VT_SYSREQ
- xf86Info.vtSysreq = value;
- xf86Msg(X_CONFIG, "VTSysReq %s\n", value ? "enabled" : "disabled");
-#else
- if (value)
- xf86Msg(X_WARNING, "VTSysReq is not supported on this OS\n");
-#endif
-}
-
xf86Info.pmFlag = TRUE;
if (xf86GetOptValBool(FlagOptions, FLAG_NOPM, &value))
xf86Info.pmFlag = !value;
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 5e56438..182b0cc 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -96,7 +96,6 @@ InputInfoPtr xf86InputDevs = NULL;
xf86InfoRec xf86Info = {
.consoleFd = -1,
.vtno = -1,
-.vtSysreq = FALSE,
.lastEventTime = -1,
.vtRequestsPending = FALSE,
#ifdef sun
diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/xf86Privstr.h
index added3c..0a08a7b 100644
--- a/hw/xfree86/common/xf86Privstr.h
+++ b/hw/xfree86/common/xf86Privstr.h
@@ -57,7 +57,6 @@ typedef enum {
typedef struct {
intconsoleFd;
intvtno;
-Bool vtSysreq;
/* event handler part */
intlastEventTime;
diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man
index f406f82..17579ee 100644
--- a/hw/xfree86/man/xorg.conf.man
+++ b/hw/xfree86/man/xorg.conf.man
@@ -560,18 +560,6 @@ drivers to not report failure if the mouse device can't be
opened/initialised.
It has no effect on the evdev(__drivermansuffix__) or other drivers.
Default: false.
.TP 7
-.BI "Option \*qVTSysReq\*q \*q" boolean \*q
-enables the SYSV\-style VT switch sequence for non\-SYSV systems
-which support VT switching.
-This sequence is
-.B Alt\-SysRq
-followed by a function key
-.RB ( Fn ).
-This prevents the __xservername__ server trapping the
-keys used for the default VT switch sequence, which means that clients can
-access them.
-Default: off.
-.TP 7
.BI "Option \*qBlankTime\*q \*q" time \*q
sets the inactivity timeout for the
.B blank
diff --git a/hw/xfree86/os-support/xf86_OSlib.h
b/hw/xfree86/os-support/xf86_OSlib.h
index fddde8a..1d59060 100644
--- a/hw/xfree86/os-support/xf86_OSlib.h
+++ b/hw/xfree86/os-support/xf86_OSlib.h
@@ -168,11 +168,6 @@
# define POSIX_TTY
# endif /* SVR4 */
-
-# if defined(sun) && defined(HAS_USL_VTS)
-# define USE_VT_SYSREQ
-# endif
-
#endif /* (SYSV || SVR4) */
/**/
@@ -207,7 +202,6 @@
# define LDSMAP PIO_SCRNMAP
# define LDNMAP LDSMAP
# define CLEARDTR_SUPPORT
-# define USE_VT_SYSREQ
# endif
# define POSIX_TTY
@@ -343,10 +337,6 @@
# define CLEARDTR_SUPPORT
-# if defined(SYSCONS_SUPPORT) || defined(PCVT_SUPPORT) ||
defined(WSCONS_SUPPORT)
-# define USE_VT_SYSREQ
-# endif
-
#endif
/* __FreeBSD_kernel__ || __NetBSD__ || __OpenBSD__ || __bsdi__ */
--
1.7.6
___
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 xserver 7/8] bsd: ioctl KDENABIO/KDDISABIO do not matter for OpenBSD
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/os-support/bsd/bsd_init.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/os-support/bsd/bsd_init.c
b/hw/xfree86/os-support/bsd/bsd_init.c
index a0caee3..c8a4e05 100644
--- a/hw/xfree86/os-support/bsd/bsd_init.c
+++ b/hw/xfree86/os-support/bsd/bsd_init.c
@@ -292,13 +292,13 @@ acquire_vt:
{
FatalError("xf86OpenConsole: VT_SETMODE VT_PROCESS
failed");
}
- #if !defined(USE_DEV_IO) && !defined(USE_I386_IOPL)
+#if !defined(__OpenBSD__) && !defined(USE_DEV_IO) && !defined(USE_I386_IOPL)
if (ioctl(xf86Info.consoleFd, KDENABIO, 0) < 0)
{
FatalError("xf86OpenConsole: KDENABIO failed (%s)",
strerror(errno));
}
- #endif
+#endif
if (ioctl(xf86Info.consoleFd, KDSETMODE, KD_GRAPHICS) < 0)
{
FatalError("xf86OpenConsole: KDSETMODE KD_GRAPHICS
failed");
@@ -648,7 +648,7 @@ xf86CloseConsole()
VT.mode = VT_AUTO;
ioctl(xf86Info.consoleFd, VT_SETMODE, &VT); /* dflt vt handling */
}
-#if !defined(OpenBSD) && !defined(USE_DEV_IO) && !defined(USE_I386_IOPL)
+#if !defined(__OpenBSD__) && !defined(USE_DEV_IO) && !defined(USE_I386_IOPL)
if (ioctl(xf86Info.consoleFd, KDDISABIO, 0) < 0)
{
xf86FatalError("xf86CloseConsole: KDDISABIO failed (%s)",
--
1.7.6
___
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 xserver 6/8] bsd: OpenBSD and NetBSD not need extra headers in PCVT_SUPPORT
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/os-support/xf86_OSlib.h | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/hw/xfree86/os-support/xf86_OSlib.h
b/hw/xfree86/os-support/xf86_OSlib.h
index cf92821..fddde8a 100644
--- a/hw/xfree86/os-support/xf86_OSlib.h
+++ b/hw/xfree86/os-support/xf86_OSlib.h
@@ -277,20 +277,14 @@
# include
#endif
# endif /* SYSCONS_SUPPORT */
-# if defined(PCVT_SUPPORT)
+# if defined(PCVT_SUPPORT) && !defined(__NetBSD__) && !defined(__OpenBSD__)
#if !defined(SYSCONS_SUPPORT)
/* no syscons, so include pcvt specific header file */
# if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
# include
# else
-# if defined(__NetBSD__) || defined(__OpenBSD__)
-# if !defined(WSCONS_SUPPORT)
-#include
-# endif /* WSCONS_SUPPORT */
-# else
-# include
-# endif /* __NetBSD__ */
-# endif /* __FreeBSD_kernel__ || __OpenBSD__ */
+# include
+# endif /* __FreeBSD_kernel__ */
#else /* pcvt and syscons: hard-code the ID magic */
# define VGAPCVTID _IOWR('V',113, struct pcvtid)
struct pcvtid {
--
1.7.6
___
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 xserver 5/8] bsd: Some clean up
OpenBSD and NetBSD does not support syscons
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/os-support/bsd/bsd_init.c |4
hw/xfree86/os-support/xf86_OSlib.h | 20
2 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/hw/xfree86/os-support/bsd/bsd_init.c
b/hw/xfree86/os-support/bsd/bsd_init.c
index 1825672..a0caee3 100644
--- a/hw/xfree86/os-support/bsd/bsd_init.c
+++ b/hw/xfree86/os-support/bsd/bsd_init.c
@@ -446,11 +446,7 @@ xf86OpenSyscons()
}
close(fd);
-#ifndef __OpenBSD__
sprintf(vtname, "/dev/ttyv%01x", xf86Info.vtno - 1);
-#else
- sprintf(vtname, "/dev/ttyC%01x", xf86Info.vtno - 1);
-#endif
if ((fd = open(vtname, SYSCONS_CONSOLE_MODE, 0)) < 0)
{
FatalError("xf86OpenSyscons: Cannot open %s (%s)",
diff --git a/hw/xfree86/os-support/xf86_OSlib.h
b/hw/xfree86/os-support/xf86_OSlib.h
index 24c92fb..cf92821 100644
--- a/hw/xfree86/os-support/xf86_OSlib.h
+++ b/hw/xfree86/os-support/xf86_OSlib.h
@@ -266,19 +266,15 @@
# else /* __bsdi__ */
# ifdef SYSCONS_SUPPORT
#define COMPAT_SYSCONS
-#if defined(__NetBSD__) || defined(__OpenBSD__)
-# include
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
+# if defined(__DragonFly__) || (__FreeBSD_kernel_version >= 41)
+# include
+# include
+# else
+# include
+# endif /* FreeBSD 4.1 RELEASE or lator */
#else
-# if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
-#if defined(__DragonFly__) || (__FreeBSD_kernel_version >= 41)
-# include
-# include
-#else
-# include
-#endif /* FreeBSD 4.1 RELEASE or lator */
-# else
-# include
-# endif
+# include
#endif
# endif /* SYSCONS_SUPPORT */
# if defined(PCVT_SUPPORT)
--
1.7.6
___
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 xserver 4/8] bsd: Remove dead code
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/os-support/bsd/bsd_init.c | 23 ---
1 files changed, 0 insertions(+), 23 deletions(-)
diff --git a/hw/xfree86/os-support/bsd/bsd_init.c
b/hw/xfree86/os-support/bsd/bsd_init.c
index 84c6b3d..1825672 100644
--- a/hw/xfree86/os-support/bsd/bsd_init.c
+++ b/hw/xfree86/os-support/bsd/bsd_init.c
@@ -211,9 +211,6 @@ xf86OpenConsole()
"%s: No console driver found\n\tSupported drivers: %s\n\t%s",
"xf86OpenConsole", cons_drivers, CHECK_DRIVER_MSG);
}
-#if 0 /* stdin is already closed in OsInit() */
- fclose(stdin);
-#endif
xf86Info.consoleFd = fd;
switch (xf86Info.consType)
@@ -372,7 +369,6 @@ xf86OpenSyscons()
int fd = -1;
vtmode_t vtmode;
char vtname[12];
-struct stat status;
long syscons_version;
MessageType from;
@@ -425,20 +421,11 @@ xf86OpenSyscons()
{
/*
* All VTs are in use. If initialVT was found, use it.
-* Otherwise, if stdin is a VT, use that one.
-* XXX stdin is already closed, so this won't work.
*/
if (initialVT != -1)
{
xf86Info.vtno = initialVT;
}
- else if ((fstat(0, &status) >= 0)
-&& S_ISCHR(status.st_mode)
-&& (ioctl(0, VT_GETMODE, &vtmode) >= 0))
- {
- /* stdin is a VT */
- xf86Info.vtno = minor(status.st_rdev) + 1;
- }
else
{
if (syscons_version >= 0x100)
@@ -508,7 +495,6 @@ xf86OpenPcvt()
int fd = -1;
vtmode_t vtmode;
char vtname[12], *vtprefix;
-struct stat status;
struct pcvtid pcvt_version;
#ifndef __OpenBSD__
@@ -554,20 +540,11 @@ xf86OpenPcvt()
{
/*
* All VTs are in use. If initialVT was found, use it.
-* Otherwise, if stdin is a VT, use that one.
-* XXX stdin is already closed, so this won't work.
*/
if (initialVT != -1)
{
xf86Info.vtno = initialVT;
}
- else if ((fstat(0, &status) >= 0)
-&& S_ISCHR(status.st_mode)
-&& (ioctl(0, VT_GETMODE, &vtmode) >= 0))
- {
- /* stdin is a VT */
- xf86Info.vtno = minor(status.st_rdev) + 1;
- }
else
{
FatalError("%s: Cannot find a free VT",
--
1.7.6
___
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 xserver 3/8] bsd: Variable devConsoleFd need only if defined PCCONS_SUPPORT
Signed-off-by: Alexandr Shadchin --- hw/xfree86/os-support/bsd/bsd_init.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/os-support/bsd/bsd_init.c b/hw/xfree86/os-support/bsd/bsd_init.c index e5c8495..84c6b3d 100644 --- a/hw/xfree86/os-support/bsd/bsd_init.c +++ b/hw/xfree86/os-support/bsd/bsd_init.c @@ -41,7 +41,10 @@ #include static Bool KeepTty = FALSE; + +#ifdef PCCONS_SUPPORT static int devConsoleFd = -1; +#endif #if defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT) static int VTnum = -1; static int initialVT = -1; @@ -694,8 +697,10 @@ xf86CloseConsole() } close(xf86Info.consoleFd); +#ifdef PCCONS_SUPPORT if (devConsoleFd >= 0) close(devConsoleFd); +#endif return; } -- 1.7.6 ___ 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 xserver 2/8] bsd: Replacement screenFd on consoleFd because they are equivalent
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/common/xf86Globals.c |1 -
hw/xfree86/common/xf86Privstr.h |2 --
hw/xfree86/os-support/bsd/alpha_video.c |2 +-
hw/xfree86/os-support/bsd/arm_video.c |6 +++---
hw/xfree86/os-support/bsd/bsd_init.c | 13 +
hw/xfree86/os-support/bsd/i386_video.c|2 +-
hw/xfree86/os-support/bsd/ppc_video.c |4 ++--
hw/xfree86/os-support/bsd/sparc64_video.c |2 +-
8 files changed, 9 insertions(+), 23 deletions(-)
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 16d5557..5e56438 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -109,7 +109,6 @@ xf86InfoRec xf86Info = {
.caughtSignal = FALSE,
.currentScreen = NULL,
#ifdef CSRG_BASED
-.screenFd = -1,
.consType = -1,
#endif
.allowMouseOpenFail = FALSE,
diff --git a/hw/xfree86/common/xf86Privstr.h b/hw/xfree86/common/xf86Privstr.h
index 608f9bd..added3c 100644
--- a/hw/xfree86/common/xf86Privstr.h
+++ b/hw/xfree86/common/xf86Privstr.h
@@ -74,8 +74,6 @@ typedef struct {
/* graphics part */
ScreenPtr currentScreen;
#if defined(CSRG_BASED) || defined(__FreeBSD_kernel__)
-intscreenFd; /* fd for memory mapped access
to
-* vga card */
intconsType; /* Which console driver? */
#endif
diff --git a/hw/xfree86/os-support/bsd/alpha_video.c
b/hw/xfree86/os-support/bsd/alpha_video.c
index bb3a5cb..15eb2a4 100644
--- a/hw/xfree86/os-support/bsd/alpha_video.c
+++ b/hw/xfree86/os-support/bsd/alpha_video.c
@@ -340,7 +340,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int flags)
base = mmap(0, Size,
(flags & VIDMEM_READONLY) ?
PROT_READ : (PROT_READ | PROT_WRITE),
- MAP_FLAGS, xf86Info.screenFd,
+ MAP_FLAGS, xf86Info.consoleFd,
(unsigned long)Base + BUS_BASE);
if (base == MAP_FAILED)
{
diff --git a/hw/xfree86/os-support/bsd/arm_video.c
b/hw/xfree86/os-support/bsd/arm_video.c
index 482d53f..eb631a7 100644
--- a/hw/xfree86/os-support/bsd/arm_video.c
+++ b/hw/xfree86/os-support/bsd/arm_video.c
@@ -213,7 +213,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int flags)
base = mmap(0, Size,
(flags & VIDMEM_READONLY) ?
PROT_READ : (PROT_READ | PROT_WRITE),
- MAP_FLAGS, xf86Info.screenFd,
+ MAP_FLAGS, xf86Info.consoleFd,
(unsigned long)Base - 0xA);
if (base == MAP_FAILED)
{
@@ -306,7 +306,7 @@ checkMapInfo(Bool warn, int Region)
if(!memAccP->Checked)
{
- if(ioctl(xf86Info.screenFd, memAccP->ioctl, &(memAccP->memInfo)) == -1)
+ if(ioctl(xf86Info.consoleFd, memAccP->ioctl, &(memAccP->memInfo)) == -1)
{
if(warn)
{
@@ -360,7 +360,7 @@ xf86MapInfoMap(struct memAccess *memInfoP, pointer Base,
unsigned long Size)
Size,
PROT_READ | PROT_WRITE,
MAP_SHARED,
-xf86Info.screenFd,
+xf86Info.consoleFd,
(unsigned long)mapInfoP->u.map_info_mmap.map_offset))
== (pointer)-1)
{
diff --git a/hw/xfree86/os-support/bsd/bsd_init.c
b/hw/xfree86/os-support/bsd/bsd_init.c
index 123eb17..e5c8495 100644
--- a/hw/xfree86/os-support/bsd/bsd_init.c
+++ b/hw/xfree86/os-support/bsd/bsd_init.c
@@ -212,7 +212,6 @@ xf86OpenConsole()
fclose(stdin);
#endif
xf86Info.consoleFd = fd;
- xf86Info.screenFd = fd;
switch (xf86Info.consType)
{
@@ -688,22 +687,12 @@ xf86CloseConsole()
case WSCONS:
{
int mode = WSDISPLAYIO_MODE_EMUL;
- ioctl(xf86Info.screenFd, WSDISPLAYIO_SMODE, &mode);
+ ioctl(xf86Info.consoleFd, WSDISPLAYIO_SMODE, &mode);
break;
}
#endif
}
-if (xf86Info.screenFd != xf86Info.consoleFd)
-{
- close(xf86Info.screenFd);
- close(xf86Info.consoleFd);
- if ((xf86Info.consoleFd = open("/dev/console",O_RDONLY,0)) <0)
- {
- xf86FatalError("xf86CloseConsole: Cannot open /dev/console (%s)",
- strerror(errno));
- }
-}
close(xf86Info.consoleFd);
if (devConsoleFd >= 0)
close(devConsoleFd);
diff --git a/hw/xfree86/os-support/bsd/i386_video.c
b/hw/xfree86/os-support/bsd/i386_video.c
index 7aef079..525bfb6 100644
--- a/hw/xfree86/os-support/bsd/i386_video.c
+++ b/hw/xfree86/os-support/bsd/i386_video.c
@@ -258,7 +258,7 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int flags)
base =
[PATCH xserver 1/8] bsd: Remove unused macros KBD_FD
Signed-off-by: Alexandr Shadchin
---
hw/xfree86/os-support/bsd/bsd_bell.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/os-support/bsd/bsd_bell.c
b/hw/xfree86/os-support/bsd/bsd_bell.c
index 55eb752..fb457db 100644
--- a/hw/xfree86/os-support/bsd/bsd_bell.c
+++ b/hw/xfree86/os-support/bsd/bsd_bell.c
@@ -37,10 +37,6 @@
#include "xf86Priv.h"
#include "xf86_OSlib.h"
-#ifdef WSCONS_SUPPORT
-#define KBD_FD(i) ((i).kbdFd != -1 ? (i).kbdFd : (i).consoleFd)
-#endif
-
void
xf86OSRingBell(int loudness, int pitch, int duration)
{
--
1.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Thu, 15 Sep 2011 12:34:51 -0400, Alex Deucher wrote: > The number of ABI breaks is minimal (usually 1 per > xserver) and those can usually be fixed within a day or so of the > breakage. We don't get ABI changes because they're nearly impossible to handle. > I don't rebuild the xserver nearly as often as I rebuild > the ddx so it would mean more work to keep up with the xserver changes > on a regular basis. On the plus side, we'd get a whole lot more coverage of new X server betas before release... -- keith.pack...@intel.com pgpT1mVFnzzEF.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: Xserver driver merging pros & cons
On Thu, Sep 15, 2011 at 5:34 PM, Alex Deucher wrote: > On Thu, Sep 15, 2011 at 11:45 AM, Jesse Barnes > wrote: >> At XDC this week we discussed merging drivers back into the server >> tree. One thing I found frustrating about the discussion was that we >> didn't have a whiteboard nor a list of the pros & cons of such a >> change. So I'd like to capture that here (from memory) to let us >> continue the discussion about whether it's worth it or not. >> >> Luc, I think you're the most vocal opponent of this move, so I've cc'd >> you so you can enumerate any issues I've forgotten. >> >> Anyway, as I recall, the issues are as follows: >> >> Pros: >> 1) easier to propagate API changes across drivers (just like Linux) >> 1a) thus easier to change ABI >> 2) developers focused on driver development now have more incentive >> to make sure the server works well so regular releases can still >> happen (i.e. more people working on blockers whether driver or not >> as releases approach) >> 3) allows removal of driver compat code for various server versions >> 3a) thus removes combinations of driver+server that developers >> have to support & test >> 4) increased test coverage for the server as users wanting current >> driver code will be building new servers too >> >> Cons: >> 1) more work for distros to backport just driver changes to old >> servers (especially if people follow through on (3) above) >> 1a) if backporting is harder, new hardware support will be more >> difficult to land in "enterprise" level distros >> 2) harder for users to just upgrade drivers independently, now >> they'll have to build the whole server >> 2a) thus less testing of current driver code from technical users >> >> I've already made my views pretty clear; I'd prefer merging the drivers >> back in. But I don't do as much work on the DIX or DDX as I used to, >> and lots of others would be affected as well, so I'd like to hear what >> people think. Have I captured the pros & cons fully? What to distro >> maintainers think? And driver developers, both input & output? > > For me personally, I don't seem much advantage in moving the drivers > into the xserver. The number of ABI breaks is minimal (usually 1 per > xserver) and those can usually be fixed within a day or so of the > breakage. I don't rebuild the xserver nearly as often as I rebuild > the ddx so it would mean more work to keep up with the xserver changes > on a regular basis. For unmaintained drivers, this might be an > advantage, but at this point the unmaintained drivers are just about > all for hardware >10 years old, so I'm not sure how important it is to > continue to pretend we still support them. > > Additionally, as was shown in Jeremy's slides, the number of changes > in the Xserver has been going down with each successive release. It > doesn't seem untenable to keep maintained external drivers in sync. > At the moment I have a large project in the works to redo the driver ABI, its pretty much an impossible project no matter what happens, its a major ABI change and will pretty much require major reworks off all the drivers. Now I've no idea how to do this with the current model, even with the drivers merged its going to be a real pain to land, thats if I ever even get it to a useable stage. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Xserver driver merging pros & cons
On Thu, Sep 15, 2011 at 11:45 AM, Jesse Barnes wrote: > At XDC this week we discussed merging drivers back into the server > tree. One thing I found frustrating about the discussion was that we > didn't have a whiteboard nor a list of the pros & cons of such a > change. So I'd like to capture that here (from memory) to let us > continue the discussion about whether it's worth it or not. > > Luc, I think you're the most vocal opponent of this move, so I've cc'd > you so you can enumerate any issues I've forgotten. > > Anyway, as I recall, the issues are as follows: > > Pros: > 1) easier to propagate API changes across drivers (just like Linux) > 1a) thus easier to change ABI > 2) developers focused on driver development now have more incentive > to make sure the server works well so regular releases can still > happen (i.e. more people working on blockers whether driver or not > as releases approach) > 3) allows removal of driver compat code for various server versions > 3a) thus removes combinations of driver+server that developers > have to support & test > 4) increased test coverage for the server as users wanting current > driver code will be building new servers too > > Cons: > 1) more work for distros to backport just driver changes to old > servers (especially if people follow through on (3) above) > 1a) if backporting is harder, new hardware support will be more > difficult to land in "enterprise" level distros > 2) harder for users to just upgrade drivers independently, now > they'll have to build the whole server > 2a) thus less testing of current driver code from technical users > > I've already made my views pretty clear; I'd prefer merging the drivers > back in. But I don't do as much work on the DIX or DDX as I used to, > and lots of others would be affected as well, so I'd like to hear what > people think. Have I captured the pros & cons fully? What to distro > maintainers think? And driver developers, both input & output? For me personally, I don't seem much advantage in moving the drivers into the xserver. The number of ABI breaks is minimal (usually 1 per xserver) and those can usually be fixed within a day or so of the breakage. I don't rebuild the xserver nearly as often as I rebuild the ddx so it would mean more work to keep up with the xserver changes on a regular basis. For unmaintained drivers, this might be an advantage, but at this point the unmaintained drivers are just about all for hardware >10 years old, so I'm not sure how important it is to continue to pretend we still support them. Additionally, as was shown in Jeremy's slides, the number of changes in the Xserver has been going down with each successive release. It doesn't seem untenable to keep maintained external drivers in sync. Alex ___ 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 fonts-util 2/2] If cross-compiling, we don't have to run mkfontdir
On 14/09/2011 00:09, Jeremy Huddleston wrote:
This is confusing to me. Why do you add the extra " ; echo '** mkfontdir'"?
On Sep 12, 2011, at 9:18 AM, Jon TURNEY wrote:
+AC_DEFUN([XORG_FONT_MKFONTDIR],[
+ if test x"$cross_compiling" != x"no" ; then
+ AC_PATH_PROG(MKFONTDIR, mkfontdir, "")
+ MKFONTDIR_WARN='echo "** Warning: mkfontdir not run" ; echo "** Run
mkfontdir manually on host system"'
+
+ if test x"$MKFONTDIR" = x; then
+ MKFONTDIR="${MKFONTDIR_WARN} ; echo '** mkfontdir'"
+ fi
+ else
+ XORG_FONT_REQUIRED_PROG(MKFONTDIR, mkfontdir)
+ fi
+
+ AC_SUBST([MKFONTDIR])
+])
MKFONTDIR_WARN is the command to emit the warning that mkfontdir could be run,
MKFONTDIR is the actual command which will be used in the makefile, and is
supplied with a directory path, so we need to consume that, and do so by
outputting the command we would have run if mkfontdir was available
Hope that clears things up for you :-)
It looks like this suffers a bit from being patterned after the
XORG_FONT_FCCACHE macro a few lines above. This is perhaps wrong, as unlike
XORG_FONT_FCCACHE, the warning is only used in one place.
___
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 libXi] inputlib: restore original title "X Input Device Extension Library"
Somehow the title got changed during troff to docbook conversion. Latest troff version: ftp://www.x.org/pub/X11R7.0/doc/PDF/XiLib.pdf Signed-off-by: Gaetan Nadon --- specs/inputlib.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/specs/inputlib.xml b/specs/inputlib.xml index bfbf862..4be875a 100644 --- a/specs/inputlib.xml +++ b/specs/inputlib.xml @@ -8,7 +8,7 @@ - X11 Input Extension Protocol Specification + X Input Device Extension Library X Version 11, Release &fullrelvers; Version 1.0 -- 1.7.4.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: Xserver driver merging pros & cons
On Don, 2011-09-15 at 10:45 -0500, Jesse Barnes wrote: > > Pros: > 1) easier to propagate API changes across drivers (just like Linux) > 1a) thus easier to change ABI > 2) developers focused on driver development now have more incentive > to make sure the server works well so regular releases can still > happen (i.e. more people working on blockers whether driver or not > as releases approach) Incentive is one thing, feasibility is another, see below. > 3) allows removal of driver compat code for various server versions > 3a) thus removes combinations of driver+server that developers > have to support & test > 4) increased test coverage for the server as users wanting current > driver code will be building new servers too > > Cons: > 1) more work for distros to backport just driver changes to old > servers (especially if people follow through on (3) above) > 1a) if backporting is harder, new hardware support will be more > difficult to land in "enterprise" level distros > 2) harder for users to just upgrade drivers independently, now > they'll have to build the whole server > 2a) thus less testing of current driver code from technical users 3) Out of tree drivers will become second class citizens. This doesn't apply to proprietary drivers only but also e.g. to the Gallium xorg state tracker, which we may want to use for Radeons at some point (and some nouveau people have been playing with it as well, but I don't know what their plans are for it). Speaking as a radeon driver developer, merging the driver into the server tree would be unworkable at this point because since the "new development model" has been in effect, it's not possible to get even trivial changes into the server tree without a ridiculous amount of time/effort. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI 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
Xserver driver merging pros & cons
At XDC this week we discussed merging drivers back into the server tree. One thing I found frustrating about the discussion was that we didn't have a whiteboard nor a list of the pros & cons of such a change. So I'd like to capture that here (from memory) to let us continue the discussion about whether it's worth it or not. Luc, I think you're the most vocal opponent of this move, so I've cc'd you so you can enumerate any issues I've forgotten. Anyway, as I recall, the issues are as follows: Pros: 1) easier to propagate API changes across drivers (just like Linux) 1a) thus easier to change ABI 2) developers focused on driver development now have more incentive to make sure the server works well so regular releases can still happen (i.e. more people working on blockers whether driver or not as releases approach) 3) allows removal of driver compat code for various server versions 3a) thus removes combinations of driver+server that developers have to support & test 4) increased test coverage for the server as users wanting current driver code will be building new servers too Cons: 1) more work for distros to backport just driver changes to old servers (especially if people follow through on (3) above) 1a) if backporting is harder, new hardware support will be more difficult to land in "enterprise" level distros 2) harder for users to just upgrade drivers independently, now they'll have to build the whole server 2a) thus less testing of current driver code from technical users I've already made my views pretty clear; I'd prefer merging the drivers back in. But I don't do as much work on the DIX or DDX as I used to, and lots of others would be affected as well, so I'd like to hear what people think. Have I captured the pros & cons fully? What to distro maintainers think? And driver developers, both input & output? Thanks, Jesse ___ 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] Delete support for MGA's proprietary HAL: unifdef USEMGAHAL.
This patch produced with:
for f in `git grep -Fwl USEMGAHAL`; do
unifdef -B -UUSEMGAHAL $f | sponge $f
done
Adam Jackson wrote:
Hey, so, remember back in the dark ages when dualhead was this
insanely wild differentiating feature? Matrox thought it was so
special, in fact, that they hid most of the implementation of it
(and a bunch of other stuff) in a binary-only blob called the
HALlib. As you'd expect it was pretty much a cut-and-paste of
the relevant Windows code, and then some open glue to keep it
working; clientlx.c is that glue.
I guess the theory was that if you don't tell people which
registers to duplicate to implement a second pipe in their own
hardware, they won't figure it out? A pretty eyeroll-worthy
idea even at the time, and definitely not something we should be
condoning anymore.
Kill it with fire, but while you're at it, untangle the hideous
mess of MGA_HAL() macros too.
Signed-off-by: Jamey Sharp
Cc: Adam Jackson
---
So, like this? I've left the MGA_NOT_HAL macros alone because there's
only so much I can take. ;-)
src/mga.h| 38 ---
src/mga_dacG.c | 48
src/mga_driver.c | 604 --
src/mga_esc.c| 778 --
src/mga_macros.h | 11 -
src/mga_merge.c | 37 ---
6 files changed, 0 insertions(+), 1516 deletions(-)
diff --git a/src/mga.h b/src/mga.h
index c520e86..fced6aa 100644
--- a/src/mga.h
+++ b/src/mga.h
@@ -42,10 +42,6 @@
#include "mga_dri.h"
#endif
-#ifdef USEMGAHAL
-#include "client.h"
-#endif
-
typedef enum {
OPTION_SW_CURSOR,
OPTION_HW_CURSOR,
@@ -329,11 +325,6 @@ typedef enum {
typedef struct {
intlastInstance;
-#ifdef USEMGAHAL
-LPCLIENTDATA pClientStruct;
-LPBOARDHANDLE pBoard;
-LPMGAHWINFOpMgaHwInfo;
-#endif
intrefCount;
CARD32 masterFbAddress;
long masterFbMapSize;
@@ -459,12 +450,6 @@ struct mga_device_attributes {
};
typedef struct {
-#ifdef USEMGAHAL
-LPCLIENTDATA pClientStruct;
-LPBOARDHANDLE pBoard;
-LPMGAMODEINFO pMgaModeInfo;
-LPMGAHWINFOpMgaHwInfo;
-#endif
EntityInfoPtr pEnt;
struct mga_bios_values bios;
CARD8 BiosOutputMode;
@@ -650,9 +635,6 @@ typedef struct {
MGAPaletteInfo palinfo[256]; /* G400 hardware bug workaround */
FBLinearPtrLinearScratch;
Boolsoftbooted;
-#ifdef USEMGAHAL
-BoolHALLoaded;
-#endif
OptionInfoPtr Options;
/* Exa */
@@ -810,26 +792,6 @@ void MGAG200SESaveMode(ScrnInfoPtr, vgaRegPtr);
void MGAG200SERestoreMode(ScrnInfoPtr, vgaRegPtr);
void MGAG200SEHWProtect(ScrnInfoPtr, Bool);
-#ifdef USEMGAHAL
-/ ESC Call Definition ***/
-typedef struct {
-char *function;
-void (*funcptr)(ScrnInfoPtr pScrn, unsigned long *param, char *out,
DisplayModePtr pMode);
-} MGAEscFuncRec, *MGAEscFuncPtr;
-
-typedef struct {
-char function[32];
-unsigned long parameters[32];
-} EscCmdStruct;
-
-extern LPMGAMODEINFO pMgaModeInfo[2];
-extern MGAMODEINFO TmpMgaModeInfo[2];
-
-extern void MGAExecuteEscCmd(ScrnInfoPtr pScrn, char *cmdline , char *sResult,
DisplayModePtr pMode);
-void MGAFillDisplayModeStruct(DisplayModePtr pMode, LPMGAMODEINFO pModeInfo);
-//
-#endif
-
static __inline__ void
MGA_MARK_SYNC(MGAPtr pMga, ScrnInfoPtr pScrn)
{
diff --git a/src/mga_dacG.c b/src/mga_dacG.c
index fca1031..b489dea 100644
--- a/src/mga_dacG.c
+++ b/src/mga_dacG.c
@@ -1001,9 +1001,6 @@ MGAGInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
break;
case PCI_CHIP_MGAG400:
case PCI_CHIP_MGAG550:
-#ifdef USEMGAHAL
- MGA_HAL(break;);
-#endif
if (MGAISGx50(pMga))
break;
@@ -1046,9 +1043,6 @@ MGAGInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
break;
case PCI_CHIP_MGAG200_SE_A_PCI:
case PCI_CHIP_MGAG200_SE_B_PCI:
-#ifdef USEMGAHAL
- MGA_HAL(break;);
-#endif
pReg->DacRegs[ MGA1064_VREF_CTL ] = 0x03;
pReg->DacRegs[MGA1064_PIX_CLK_CTL] =
MGA1064_PIX_CLK_CTL_SEL_PLL;
@@ -1097,9 +1091,6 @@ MGAGInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
case PCI_CHIP_MGAG200:
case PCI_CHIP_MGAG200_PCI:
default:
-#ifdef USEMGAHAL
- MGA_HAL(break;);
-#endif
if(pMga->OverclockMem) {
/* 143 Mhz */
pReg->DacRegs[ MGA1064_SYS_PLL_M ] = 0x06;
@@ -1496,21 +1487,6 @@ MGA_NOT_HAL(
MGAG200EHPIXPLLSET(pScrn, mgaReg);
}
); /* MGA_NOT_HAL */
-#ifdef USEMG
Re: [PATCH] x86emu: There is no NO_INLINE implementation of unaligned access here.
On Tue, Sep 13, 2011 at 5:32 PM, Jamey Sharp wrote: > Patch produced with: > unifdef -UNO_INLINE -B > > This change isn't relevant to the similar code in > xfree86/common/compiler.h, because x86emu is expected to someday move > out of xserver entirely and so should not depend on any xserver headers. > > Signed-off-by: Jamey Sharp > --- > hw/xfree86/x86emu/sys.c | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/hw/xfree86/x86emu/sys.c b/hw/xfree86/x86emu/sys.c > index 602b0bb..f389767 100644 > --- a/hw/xfree86/x86emu/sys.c > +++ b/hw/xfree86/x86emu/sys.c > @@ -49,7 +49,6 @@ > #include > #endif > > -# ifndef NO_INLINE > # ifdef __GNUC__ Trivial, but the indentatino of ifdef __GNUC__ should probably be changed as well. Either way, Reviewed-by: Matt Turner ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
On 09/15/11 04:41 AM, Jeremy Huddleston wrote: Actually, it looks like a bunch of drivers are not linking correctly to begin with, and nobody seems so have cared. The Solaris linker does, and I've long added a bunch of libraries to my LDFLAGS for each driver on Solaris. If we're now interested in doing this on all platforms, I can work on upstreaming those. For instance: http://src.opensolaris.org/source/xref/x-cons/xnv-clone/open-src/driver/xf86-video-vesa/Makefile#48 adds -lfb -lpciaccess -lshadow -lvbe I definitely noticed in Xorg 1.10 that pretty much every module ends up linking to libpixman due to some inline functions in the headers that call libpixman functions directly. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 3/3] devbook.am: maintenance update from docbook.am
On Thu, 2011-09-15 at 02:35 -0500, Jeremy Huddleston wrote: > On Sep 14, 2011, at 9:12 AM, Gaetan Nadon wrote: > > > > +if HAVE_XMLTO_TEXT > > +noinst_DATA += $(docbook:.xml=.txt) > > +%.txt: %.xml $(chapters) > > + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< > > +endif HAVE_XMLTO_TEXT > > ^^^ XMLTO_TEXT_FLAGS ?? > > Good observation. The txt format is obtained by first transforming xml to html using the same xsltproc and stylesheet. Then it is converted to text using one of the three tools w3m, lynks or links. Although confusing, it is more accurate to use the same html flags. It also looks strange to have olink flags when you cannot have cross-reference documents between text file. So this one is good, there were no lack of opportunities for errors. Thanks signature.asc Description: This is a digitally signed message part ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
On Wed, 2011-09-14 at 20:17 -0500, Jeremy Huddleston wrote:
> Every module building against xorg-server does not *Require* pixman nor
> libpciaccess. If such modules need pixman or pciaccess, they should be
> depending on them directly rather than inheriting a dependency from
> xorg-server.
>
> This also moves pixman-1 to Requires.private, so CPPFLAGS is set right to
> to satisfy include dependencies but avoid linking needlessly.
>
Can you add in the commit text your recommendations for drivers which:
- are already released and need pciaccess; would they no longer
build (or no longer work)?
- are actively maintained and need pciaccess:
- should they bump up xserver version in PKG_CHECK_MODULES as
they now would no longer build on previous versions of xserver?
I don't have an opinion on what should or should not happen, just that
it is helpful when it is written down.
A bonus would be a list of drivers that do use pciaccess (maybe not in
the commit text!). A complete list of drivers can be found in build.sh.
> Signed-off-by: Jeremy Huddleston
> ---
> configure.ac | 11 ++-
> xorg-server.pc.in |1 -
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 415ead8..a97da47 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -785,11 +785,6 @@ VIDMODEPROTO="xf86vidmodeproto >= 2.2.99.1"
> WINDOWSWMPROTO="windowswmproto"
> APPLEWMPROTO="applewmproto >= 1.4"
>
> -dnl Core modules for most extensions, et al.
> -SDK_REQUIRED_MODULES="[xproto >= 7.0.22] [randrproto >= 1.2.99.3]
> [renderproto >= 0.11] [xextproto >= 7.1.99] [inputproto >= 1.9.99.902]
> [kbproto >= 1.0.3] fontsproto"
> -# Make SDK_REQUIRED_MODULES available for inclusion in xorg-server.pc
> -AC_SUBST(SDK_REQUIRED_MODULES)
> -
> dnl List of libraries that require a specific version
> LIBAPPLEWM="applewm >= 1.4"
> LIBDMX="dmx >= 1.0.99.1"
> @@ -811,6 +806,11 @@ dnl specific modules against it
> PKG_CHECK_MODULES(PIXMAN, $LIBPIXMAN)
> REQUIRED_LIBS="$REQUIRED_LIBS $LIBPIXMAN $LIBXFONT xau"
>
> +dnl Core modules for most extensions, et al.
> +SDK_REQUIRED_MODULES="[xproto >= 7.0.22] [randrproto >= 1.2.99.3]
> [renderproto >= 0.11] [xextproto >= 7.1.99] [inputproto >= 1.9.99.902]
> [kbproto >= 1.0.3] fontsproto $LIBPIXMAN"
> +# Make SDK_REQUIRED_MODULES available for inclusion in xorg-server.pc
> +AC_SUBST(SDK_REQUIRED_MODULES)
> +
> REQUIRED_MODULES="[fixesproto >= 5.0] [damageproto >= 1.1] [xcmiscproto >=
> 1.2.0] [xtrans >= 1.2.2] [bigreqsproto >= 1.1.0] $SDK_REQUIRED_MODULES"
>
> if test "x$CONFIG_UDEV" = xyes &&
> @@ -1561,6 +1561,7 @@ if test "x$XORG" = xyes; then
> if test "x$PCI" = xyes; then
>
> PKG_CHECK_MODULES([PCIACCESS], $LIBPCIACCESS)
> + SDK_REQUIRED_MODULES="$SDK_REQUIRED_MODULES $LIBPCIACCESS"
> XORG_SYS_LIBS="$XORG_SYS_LIBS $PCIACCESS_LIBS $GLX_SYS_LIBS"
> XORG_CFLAGS="$XORG_CFLAGS $PCIACCESS_CFLAGS"
>
> diff --git a/xorg-server.pc.in b/xorg-server.pc.in
> index fb238b5..a98eca8 100644
> --- a/xorg-server.pc.in
> +++ b/xorg-server.pc.in
> @@ -15,7 +15,6 @@ abi_extension=@abi_extension@
> Name: xorg-server
> Description: Modular X.Org X Server
> Version: @PACKAGE_VERSION@
> -Requires: pixman-1 pciaccess
> Requires.private: @SDK_REQUIRED_MODULES@
> Cflags: -I${sdkdir} @symbol_visibility@
> Libs: -L${libdir}
Reviewed-by: Gaetan Nadon
signature.asc
Description: This is a digitally signed message part
___
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 3/3] xfree86: Link modules with -module
On Thu, 2011-09-15 at 02:23 -0500, Jamey Sharp wrote: > On Wed, Sep 14, 2011 at 08:17:45PM -0500, Jeremy Huddleston wrote: > > This makes a difference on darwin (and apparently nowhere else) > > > > Signed-off-by: Jeremy Huddleston > > --- > > According to the libtool manual, "modules that can be dlopened" need > libtool's -module switch. So I think this patch is the right thing to > do > even if it doesn't make any difference on the platforms that already > supported the xfree86 DDX. > > https://www.gnu.org/s/libtool/manual/libtool.html#Modules-for-libltdl > > Therefore: > > Reviewed-by: Jamey Sharp > > But I'd also like to hear from Gaetan or somebody on this as well. I have little hands-on experience with libraries, so I tried my google luck. I did find posts that confirms what Jeremy is saying. On the MAC, a module and a shared library is different. I found a post where the converse happened. A shared library was linked to using -module and it failed. Yea, GnuCash's previous developers wanted gnucash to be a bunch of Loadable Modules.. But they never finished the modularlization, and they didn't understand the difference between a Shared Library and a Loadable Module. A couple of things to verify: * OpenBSD still uses libtool 1.5 * Solaris is different enough to get a review for this * Ensure -module is not used for shared libraries (if makefile flags are shared) Reviewed-by: Gaetan Nadon > > Jamey signature.asc Description: This is a digitally signed message part ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
On Sep 15, 2011, at 3:30 AM, Julien Cristau wrote: > On Thu, Sep 15, 2011 at 03:20:02 -0500, Jeremy Huddleston wrote: > >> Wouldn't it be nice if the servers that we cared about were in the >> xorg-server tree itself, so I could try building with these changes on a >> linux machine to see what broke. Oh wait, if we had the drivers in the tree >> to begin with we wouldn't need to do that anyways... >> >> In all seriousness, yes. This change is in xserver in this run on my >> tinderbox: >> http://tinderbox.x.org/builds/2011-09-15-0003 >> >> I just kicked it off now, so hopefully it'll give us some idea of the impact >> in the morning and I can address that before this is pulled into the server. >> Does this satisfy you enough for an Ack? >> > Not really, missing -lfoo won't result in build failures anyway. Actually, it looks like a bunch of drivers are not linking correctly to begin with, and nobody seems so have cared. My guess is that this is "just working" on Linux because of the flat namespace. Note that my example here is from my distro, not my jhbuild. Because of this, I'll create the list of ones that should be fixed, but I don't think that concern should block the commit. /usr/lib/xorg/modules/drivers $ ldd nouveau_drv.so linux-vdso32.so.1 => (0x0010) libdrm_nouveau.so.1 => /lib/powerpc-linux-gnu/libdrm_nouveau.so.1 (0x6ff84000) libudev.so.0 => /lib/powerpc-linux-gnu/libudev.so.0 (0x6ff56000) librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x6ff2d000) libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x6fd99000) libdrm.so.2 => /lib/powerpc-linux-gnu/libdrm.so.2 (0x6fd6d000) libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x6fd32000) /lib/ld.so.1 (0x203cd000) /usr/lib/xorg/modules/drivers $ nm -D nouveau_drv.so | grep pixman_ U pixman_region_copy U pixman_region_intersect U pixman_region_translate ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
Every module building against xorg-server does not *Require* pixman nor libpciaccess. If such modules need pixman or pciaccess, they should be depending on them directly rather than inheriting a dependency from xorg-server. >>> The thing is, most video drivers *do* need pixman and pciaccess, and >>> inherit that dependency from the server (not to mention the fact that >>> the server tends to hide the use of pixman_* by its own macros so it's >>> not obvious where the dependency belongs). Can we fix that first? >> >> Wouldn't it be nice if the servers that we cared about were in the >> xorg-server tree itself, so I could try building with these changes on a >> linux machine to see what broke. Oh wait, if we had the drivers in the tree >> to begin with we wouldn't need to do that anyways... >> >> In all seriousness, yes. This change is in xserver in this run on my >> tinderbox: >> http://tinderbox.x.org/builds/2011-09-15-0003 >> >> I just kicked it off now, so hopefully it'll give us some idea of the impact >> in the morning and I can address that before this is pulled into the server. >> Does this satisfy you enough for an Ack? >> > Not really, missing -lfoo won't result in build failures anyway. Right, but I can do some ldd/nm magic after the build to create a list. ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
On Thu, Sep 15, 2011 at 03:20:02 -0500, Jeremy Huddleston wrote: > > On Sep 15, 2011, at 2:58 AM, Julien Cristau wrote: > > > On Wed, Sep 14, 2011 at 20:17:41 -0500, Jeremy Huddleston wrote: > > > >> Every module building against xorg-server does not *Require* pixman nor > >> libpciaccess. If such modules need pixman or pciaccess, they should be > >> depending on them directly rather than inheriting a dependency from > >> xorg-server. > >> > > The thing is, most video drivers *do* need pixman and pciaccess, and > > inherit that dependency from the server (not to mention the fact that > > the server tends to hide the use of pixman_* by its own macros so it's > > not obvious where the dependency belongs). Can we fix that first? > > Wouldn't it be nice if the servers that we cared about were in the > xorg-server tree itself, so I could try building with these changes on a > linux machine to see what broke. Oh wait, if we had the drivers in the tree > to begin with we wouldn't need to do that anyways... > > In all seriousness, yes. This change is in xserver in this run on my > tinderbox: > http://tinderbox.x.org/builds/2011-09-15-0003 > > I just kicked it off now, so hopefully it'll give us some idea of the impact > in the morning and I can address that before this is pulled into the server. > Does this satisfy you enough for an Ack? > Not really, missing -lfoo won't result in build failures anyway. Cheers, Julien ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
On Sep 15, 2011, at 2:58 AM, Julien Cristau wrote: > On Wed, Sep 14, 2011 at 20:17:41 -0500, Jeremy Huddleston wrote: > >> Every module building against xorg-server does not *Require* pixman nor >> libpciaccess. If such modules need pixman or pciaccess, they should be >> depending on them directly rather than inheriting a dependency from >> xorg-server. >> > The thing is, most video drivers *do* need pixman and pciaccess, and > inherit that dependency from the server (not to mention the fact that > the server tends to hide the use of pixman_* by its own macros so it's > not obvious where the dependency belongs). Can we fix that first? Wouldn't it be nice if the servers that we cared about were in the xorg-server tree itself, so I could try building with these changes on a linux machine to see what broke. Oh wait, if we had the drivers in the tree to begin with we wouldn't need to do that anyways... In all seriousness, yes. This change is in xserver in this run on my tinderbox: http://tinderbox.x.org/builds/2011-09-15-0003 I just kicked it off now, so hopefully it'll give us some idea of the impact in the morning and I can address that before this is pulled into the server. Does this satisfy you enough for an Ack? ___ 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/3] xorg-server.pc.in: Remove libpciaccess and pixman-1 from Requires
On Wed, Sep 14, 2011 at 20:17:41 -0500, Jeremy Huddleston wrote: > Every module building against xorg-server does not *Require* pixman nor > libpciaccess. If such modules need pixman or pciaccess, they should be > depending on them directly rather than inheriting a dependency from > xorg-server. > The thing is, most video drivers *do* need pixman and pciaccess, and inherit that dependency from the server (not to mention the fact that the server tends to hide the use of pixman_* by its own macros so it's not obvious where the dependency belongs). Can we fix that first? Cheers, Julien ___ 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: Rename wfbTriangles and wfbTrapezoids
Reviewed-by: Jeremy Huddleston On Sep 14, 2011, at 5:25 PM, Aaron Plattner wrote: > These symbols were not renamed when they were added to libfb: > > # nm -D libwfb.so | grep ' fb' > 00028d00 T fbTrapezoids > 00028d60 T fbTriangles > > This causes corruption and/or crashes on wfb-ful drivers like nvidia: > > Program received signal SIGABRT, Aborted. > 0x7fd67f3a0405 in *__GI_raise (sig=) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > in ../nptl/sysdeps/unix/sysv/linux/raise.c > (gdb) bt > #0 0x7fd67f3a0405 in *__GI_raise (sig=) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x7fd67f3a3680 in *__GI_abort () at abort.c:92 > #2 0x7fd67f3995b1 in *__GI___assert_fail (assertion=0x7fd679ecb804 > "key->initialized", file=, line=116, function=0x7fd679ecbbc0 > "dixGetPrivateAddr") > at assert.c:81 > #3 0x7fd679ec55b6 in ?? () from /usr/lib/xorg/modules/libfb.so > #4 0x7fd679eca9ef in ?? () from /usr/lib/xorg/modules/libfb.so > #5 0x7fd679ecae20 in fbTriangles () from /usr/lib/xorg/modules/libfb.so > #6 0x7fd67a58fc55 in ?? () from > /usr/lib/xorg/modules/drivers/nvidia_drv.so > #7 0x004f38d1 in ?? () > #8 0x00437ae9 in ?? () > #9 0x00426eaa in ?? () > #10 0x7fd67f38cead in __libc_start_main (main=, > argc=, ubp_av=, init=, > fini=, > rtld_fini=, stack_end=0x7fff99860d78) at libc-start.c:228 > #11 0x0042719d in _start () > > Signed-off-by: Aaron Plattner > --- > fb/wfbrename.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/fb/wfbrename.h b/fb/wfbrename.h > index e855edd..8b896eb 100644 > --- a/fb/wfbrename.h > +++ b/fb/wfbrename.h > @@ -160,6 +160,8 @@ > #define fbStippleTable wfbStippleTable > #define fbTile wfbTile > #define fbTransparentSpan wfbTransparentSpan > +#define fbTrapezoids wfbTrapezoids > +#define fbTriangles wfbTriangles > #define fbUninstallColormap wfbUninstallColormap > #define fbUnmapWindow wfbUnmapWindow > #define fbUnrealizeFont wfbUnrealizeFont > -- > 1.7.4.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 > --- Jeremy Huddleston Rebuild Sudan - Board of Directors - http://www.rebuildsudan.org Berkeley Foundation for Opportunities in Information Technology - Advisory Board - http://www.bfoit.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Delete #if 0'd implementation that's older than our git history.
Reviewed-by: Jeremy Huddleston
On Sep 14, 2011, at 12:27 PM, Jamey Sharp wrote:
> Throughout the xserver git history, the generic portion of the int10
> module has always used other methods for reading the video BIOS. For
> some time now it's been purely libpciaccess based. This commented-out
> use of xf86ReadBIOS is entirely superfluous.
>
> Signed-off-by: Jamey Sharp
> ---
> hw/xfree86/int10/generic.c | 14 +-
> 1 files changed, 1 insertions(+), 13 deletions(-)
>
> diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
> index fe8bb69..9940854 100644
> --- a/hw/xfree86/int10/generic.c
> +++ b/hw/xfree86/int10/generic.c
> @@ -128,10 +128,6 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
> int screen;
> legacyVGARec vga;
>
> -#if 0
> -CARD32 cs;
> -#endif
> -
> screen = (xf86FindScreenForEntity(entityIndex))->scrnIndex;
>
> options = xf86HandleInt10Options(xf86Screens[screen],entityIndex);
> @@ -174,17 +170,9 @@ xf86ExtendedInitInt10(int entityIndex, int Flags)
>
> /*
> * Retrieve everything between V_BIOS and SYS_BIOS as some system BIOSes
> - * have executable code there. Note that xf86ReadBIOS() can only read in
> - * 64kB at a time.
> + * have executable code there.
> */
> memset((char *)base + V_BIOS, 0, SYS_BIOS - V_BIOS);
> -#if 0
> -for (cs = V_BIOS; cs < SYS_BIOS; cs += V_BIOS_SIZE)
> - if (xf86ReadBIOS(cs, 0, (unsigned char *)base + cs, V_BIOS_SIZE) <
> - V_BIOS_SIZE)
> - xf86DrvMsg(screen, X_WARNING,
> -"Unable to retrieve all of segment 0x%06X.\n", cs);
> -#endif
> INTPriv(pInt)->highMemory = V_BIOS;
>
> if (xf86IsEntityPrimary(entityIndex) && !(initPrimary(options))) {
> --
> 1.7.5.4
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
---
Jeremy Huddleston
Rebuild Sudan
- Board of Directors
- http://www.rebuildsudan.org
Berkeley Foundation for Opportunities in Information Technology
- Advisory Board
- http://www.bfoit.org
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH lib/libxtrans] Removing SUN specific code, let solaris create .X11-pipe with sticky bit on
Reviewed-by: Jeremy Huddleston
On Sep 14, 2011, at 12:05 PM, Arvind Umrao wrote:
> In solaris, /tmp/.X11-unix/ is already created with privilege
> drwxrwxrwt(01777), there is no reason to restrict /tmp/.X11-pipe with
> drwxrwxr-x (0775). So I have removed unwanted sun specific code.
>
> Alan told me, named pipe support was added around Solaris 2.6 when that was a
> much better performing transport than Unix sockets on the Solaris kernels of
> the time. By Solaris 10, Unix sockets had been reimplemented in the kernel to
> be faster, so they became the default again. In Solaris 11, we don't even
> have named pipe support in the libxcb library that implements X client
> connection code now, so the named pipes would only be accessed by code with a
> different libX11 or a statically linked libX11 from Solaris 2.6-9
>
> Signed-off-by: Arvind Umrao
> ---
> Xtranslcl.c |4
> 1 files changed, 0 insertions(+), 4 deletions(-)
>
> diff --git a/Xtranslcl.c b/Xtranslcl.c
> index ca04e7f..239d8d2 100644
> --- a/Xtranslcl.c
> +++ b/Xtranslcl.c
> @@ -742,15 +742,11 @@ TRANS(NAMEDOpenPipe)(const char *server_path)
> struct stat sbuf;
> int mode;
>
> -#if defined(sun)&& defined(X11_t)
> -mode = 0775; /* Solaris requires uid or gid 0 to create X11 pipes */
> -#else
> #ifdef HAS_STICKY_DIR_BIT
> mode = 01777;
> #else
> mode = 0777;
> #endif
> -#endif
> if (trans_mkdir(X_STREAMS_DIR, mode) == -1) {
> PRMSG (1, "NAMEDOpenPipe: mkdir(%s) failed, errno = %d\n",
> X_STREAMS_DIR, errno, 0);
> --
> 1.7.6
>
>
> ___
> 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
Re: [PATCH xserver 3/3] devbook.am: maintenance update from docbook.am
On Sep 14, 2011, at 9:12 AM, Gaetan Nadon wrote: > > +if HAVE_XMLTO_TEXT > +noinst_DATA += $(docbook:.xml=.txt) > +%.txt: %.xml $(chapters) > + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< > +endif HAVE_XMLTO_TEXT ^^^ XMLTO_TEXT_FLAGS ?? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/3] docbook.am: global maintenance update - entities, images and olinking
Loosely reviewed ... the magic looks reasonable to me, but I'm not terribly familiar with the docbook internals to know if it's really the right magic. Reviewed-by: Jeremy Huddleston On Sep 14, 2011, at 9:12 AM, Gaetan Nadon wrote: > Adding support in libX11 for html chunking caused a reorg of docbook.am > as well as the xorg-sgml-doctools masterdb for olinking. > The parameter img.src.path is added for pdf images. > A searchpath to the root builddir is added for local entities, if present. > This feature was initiated by xserver module and made available to all. > > The docbook.am makefile hides all the details and is identical for > all 22 modules having DocBook documentation. It is included by a thin > Makefile.am which requires no docbook knowledge. > > Signed-off-by: Gaetan Nadon > --- > docbook.am | 116 > 1 files changed, 62 insertions(+), 54 deletions(-) > > diff --git a/docbook.am b/docbook.am > index eb3bf0c..9377f5b 100644 > --- a/docbook.am > +++ b/docbook.am > @@ -21,76 +21,84 @@ shelf_DATA = > dist_shelf_DATA = $(docbook) $(chapters) > > if HAVE_XMLTO > -# > -# Generate DocBook/XML output formats with or without stylesheets > -# > - > -# Stylesheets are available if the package xorg-sgml-doctools is installed > if HAVE_STYLESHEETS > > -# The location where all cross reference databases are installed > -sgmldbsdir = $(XORG_SGML_PATH)/X11/dbs > -masterdb = "$(sgmldbsdir)/masterdb$(suffix $@).xml" > -XMLTO_FLAGS =\ > - --searchpath "$(XORG_SGML_PATH)/X11"\ > - --searchpath "$(abs_top_builddir)" \ > - --stringparam target.database.document=$(masterdb) \ > - --stringparam current.docid="$(<:.xml=)"\ > - --stringparam collect.xref.targets="no" > - > -XMLTO_XHTML_FLAGS = \ > - -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl \ > - --stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css > - > -XMLTO_FO_FLAGS = \ > - -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl > -endif HAVE_STYLESHEETS > +XMLTO_SEARCHPATH_FLAGS = \ > + --searchpath "$(XORG_SGML_PATH)/X11"\ > + --searchpath "$(abs_top_builddir)" > +XMLTO_HTML_OLINK_FLAGS = \ > + --stringparam > target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \ > + --stringparam current.docid="$(<:.xml=)" > +XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl > +XMLTO_HTML_CSS_STYLESHEET_FLAGS = --stringparam > html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css > +XMLTO_HTML_FLAGS = \ > + $(XMLTO_SEARCHPATH_FLAGS) \ > + $(XMLTO_HTML_STYLESHEET_FLAGS) \ > + $(XMLTO_HTML_CSS_STYLESHEET_FLAGS) \ > + $(XMLTO_HTML_OLINK_FLAGS) > > shelf_DATA += $(docbook:.xml=.html) > -%.html: %.xml $(chapters) > - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) xhtml-nochunks > $< > - > -if HAVE_FOP > -shelf_DATA += $(docbook:.xml=.pdf) $(docbook:.xml=.ps) > -%.pdf: %.xml $(chapters) > - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop pdf $< > -%.ps: %.xml $(chapters) > - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_FO_FLAGS) --with-fop ps $< > -endif HAVE_FOP > +%.html: %.xml $(chapters) > + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $< > > if HAVE_XMLTO_TEXT > + > shelf_DATA += $(docbook:.xml=.txt) > %.txt: %.xml $(chapters) > - $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) $(XMLTO_XHTML_FLAGS) txt $< > + $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $< > endif HAVE_XMLTO_TEXT > > -# > -# Generate documents cross-reference target databases > -# > +if HAVE_FOP > +XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/ > +XMLTO_PDF_OLINK_FLAGS = \ > + --stringparam > target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \ > + --stringparam current.docid="$(<:.xml=)" > +XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl > + > +XMLTO_FO_FLAGS = \ > + $(XMLTO_SEARCHPATH_FLAGS) \ > + $(XMLTO_FO_STYLESHEET_FLAGS)\ > + $(XMLTO_FO_IMAGEPATH_FLAGS) \ > + $(XMLTO_PDF_OLINK_FLAGS) > + > +shelf_DATA += $(docbook:.xml=.pdf) > +%.pdf: %.xml $(chapters) > + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $< > > -# This is only possible if the xorg-sgml-doctools package is installed > -if HAVE_STYLESHEETS > -if HAVE_XSLTPROC > +shelf_DATA += $(docbook:.xml=.ps) > +%.ps: %.xml $(chapters) > + $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $< > +endif HAVE_FOP > > -# DocBook/XML generated document cross-reference database > -shelf_DATA += $(docbook:.xml=.html.db) $(docbook:.xml=.fo.db) > +# Generate documents cross-reference target databases > +if HAVE_XSLTPROC > > -# Generate DocBo
Re: [PATCH xserver 2/3] docbook.am: embed css styles inside the HTML HEAD element
Reviewed-by: Jeremy Huddleston On Sep 14, 2011, at 9:12 AM, Gaetan Nadon wrote: > Rather than referring to the external xorg.css stylesheet, embed the content > of the file in the html output produced. This is accomplished by using > version 1.10 of xorg-xhtml.xsl. > > This makes the whole html docs tree much more relocatable. > In addition, it eliminates xorg.css as a runtime file which makes > xorg-sgml-doctools a build time only package. > > Signed-off-by: Gaetan Nadon > --- > docbook.am |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/docbook.am b/docbook.am > index 9377f5b..bba4d54 100644 > --- a/docbook.am > +++ b/docbook.am > @@ -30,11 +30,9 @@ XMLTO_HTML_OLINK_FLAGS = \ > --stringparam > target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \ > --stringparam current.docid="$(<:.xml=)" > XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl > -XMLTO_HTML_CSS_STYLESHEET_FLAGS = --stringparam > html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css > XMLTO_HTML_FLAGS =\ > $(XMLTO_SEARCHPATH_FLAGS) \ > $(XMLTO_HTML_STYLESHEET_FLAGS) \ > - $(XMLTO_HTML_CSS_STYLESHEET_FLAGS) \ > $(XMLTO_HTML_OLINK_FLAGS) > > shelf_DATA += $(docbook:.xml=.html) > -- > 1.7.4.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 > --- Jeremy Huddleston Rebuild Sudan - Board of Directors - http://www.rebuildsudan.org Berkeley Foundation for Opportunities in Information Technology - Advisory Board - http://www.bfoit.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/3] xfree86: fbdevhw: Remove unused include of pciaccess.h
Reviewed-by: Jamey Sharp On Wed, Sep 14, 2011 at 08:17:39PM -0500, Jeremy Huddleston wrote: > > Signed-off-by: Jeremy Huddleston > --- > hw/xfree86/fbdevhw/fbdevhw.h |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/hw/xfree86/fbdevhw/fbdevhw.h b/hw/xfree86/fbdevhw/fbdevhw.h > index bc46b9c..34870c2 100644 > --- a/hw/xfree86/fbdevhw/fbdevhw.h > +++ b/hw/xfree86/fbdevhw/fbdevhw.h > @@ -5,8 +5,6 @@ > #include "xf86str.h" > #include "colormapst.h" > > -#include > - > #define FBDEVHW_PACKED_PIXELS0 /* Packed Pixels > */ > #define FBDEVHW_PLANES 1 /* Non interleaved > planes */ > #define FBDEVHW_INTERLEAVED_PLANES 2 /* Interleaved planes */ > -- > 1.7.6.1 > > signature.asc Description: 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 3/3] xfree86: Link modules with -module
On Wed, Sep 14, 2011 at 08:17:45PM -0500, Jeremy Huddleston wrote: > This makes a difference on darwin (and apparently nowhere else) > > Signed-off-by: Jeremy Huddleston > --- According to the libtool manual, "modules that can be dlopened" need libtool's -module switch. So I think this patch is the right thing to do even if it doesn't make any difference on the platforms that already supported the xfree86 DDX. https://www.gnu.org/s/libtool/manual/libtool.html#Modules-for-libltdl Therefore: Reviewed-by: Jamey Sharp But I'd also like to hear from Gaetan or somebody on this as well. Jamey > hw/xfree86/dixmods/Makefile.am| 12 ++-- > hw/xfree86/dixmods/extmod/Makefile.am |2 +- > hw/xfree86/exa/Makefile.am|2 +- > hw/xfree86/fbdevhw/Makefile.am|2 +- > hw/xfree86/ramdac/Makefile.am |1 + > hw/xfree86/shadowfb/Makefile.am |2 +- > hw/xfree86/vbe/Makefile.am|2 +- > hw/xfree86/xaa/Makefile.am|2 +- > 8 files changed, 13 insertions(+), 12 deletions(-) > > diff --git a/hw/xfree86/dixmods/Makefile.am b/hw/xfree86/dixmods/Makefile.am > index 1a162ab..b6eb54f 100644 > --- a/hw/xfree86/dixmods/Makefile.am > +++ b/hw/xfree86/dixmods/Makefile.am > @@ -30,21 +30,21 @@ INCLUDES = @XORG_INCS@ \ > -I$(top_srcdir)/miext/shadow \ > -I$(top_srcdir)/glx > > -libdbe_la_LDFLAGS = -avoid-version > +libdbe_la_LDFLAGS = -module -avoid-version > libdbe_la_LIBADD = $(top_builddir)/dbe/libdbe.la > libdbe_la_SOURCES = dbemodule.c > > -libfb_la_LDFLAGS = -avoid-version > +libfb_la_LDFLAGS = -module -avoid-version > libfb_la_LIBADD = $(top_builddir)/fb/libfb.la > libfb_la_SOURCES = $(top_builddir)/fb/fbcmap_mi.c fbmodule.c > libfb_la_CFLAGS = $(AM_CFLAGS) > > -libwfb_la_LDFLAGS = -avoid-version > +libwfb_la_LDFLAGS = -module -avoid-version > libwfb_la_LIBADD = $(top_builddir)/fb/libwfb.la > libwfb_la_SOURCES = $(top_builddir)/fb/fbcmap_mi.c fbmodule.c > libwfb_la_CFLAGS = $(AM_CFLAGS) -DFB_ACCESS_WRAPPER > > -libglx_la_LDFLAGS = -avoid-version > +libglx_la_LDFLAGS = -module -avoid-version > if AIGLX_DRI_LOADER > GLXDRI_LIBRARY = $(top_builddir)/glx/libglxdri.la > endif > @@ -53,11 +53,11 @@ libglx_la_LIBADD = \ > $(GLXDRI_LIBRARY) > libglx_la_SOURCES = glxmodule.c > > -librecord_la_LDFLAGS = -avoid-version > +librecord_la_LDFLAGS = -module -avoid-version > librecord_la_LIBADD = $(top_builddir)/record/librecord.la > librecord_la_SOURCES = recordmod.c > > -libshadow_la_LDFLAGS = -avoid-version > +libshadow_la_LDFLAGS = -module -avoid-version > libshadow_la_LIBADD = $(top_builddir)/miext/shadow/libshadow.la > libshadow_la_SOURCES = shmodule.c > > diff --git a/hw/xfree86/dixmods/extmod/Makefile.am > b/hw/xfree86/dixmods/extmod/Makefile.am > index cce19f7..87c28a4 100644 > --- a/hw/xfree86/dixmods/extmod/Makefile.am > +++ b/hw/xfree86/dixmods/extmod/Makefile.am > @@ -21,7 +21,7 @@ INCLUDES = @XORG_INCS@ \ > -I$(top_srcdir)/hw/xfree86/loader \ > -I$(top_srcdir)/miext/shadow > > -libextmod_la_LDFLAGS = -avoid-version > +libextmod_la_LDFLAGS = -module -avoid-version > libextmod_la_SOURCES = modinit.c \ > modinit.h \ > $(DGA_SRCS) \ > diff --git a/hw/xfree86/exa/Makefile.am b/hw/xfree86/exa/Makefile.am > index 39f7a90..3ced531 100644 > --- a/hw/xfree86/exa/Makefile.am > +++ b/hw/xfree86/exa/Makefile.am > @@ -2,7 +2,7 @@ SUBDIRS = man > > module_LTLIBRARIES = libexa.la > > -libexa_la_LDFLAGS = -avoid-version > +libexa_la_LDFLAGS = -module -avoid-version > > INCLUDES = \ > $(XORG_INCS) \ > diff --git a/hw/xfree86/fbdevhw/Makefile.am b/hw/xfree86/fbdevhw/Makefile.am > index 2a03890..4472acd 100644 > --- a/hw/xfree86/fbdevhw/Makefile.am > +++ b/hw/xfree86/fbdevhw/Makefile.am > @@ -2,7 +2,7 @@ SUBDIRS = man > > module_LTLIBRARIES = libfbdevhw.la > > -libfbdevhw_la_LDFLAGS = -avoid-version > +libfbdevhw_la_LDFLAGS = -module -avoid-version > > if FBDEVHW > libfbdevhw_la_SOURCES = fbdevhw.c > diff --git a/hw/xfree86/ramdac/Makefile.am b/hw/xfree86/ramdac/Makefile.am > index 3c37805..d29ded5 100644 > --- a/hw/xfree86/ramdac/Makefile.am > +++ b/hw/xfree86/ramdac/Makefile.am > @@ -1,5 +1,6 @@ > noinst_LTLIBRARIES = libramdac.la > > +libramdac_la_LDFLAGS = -module -avoid-version > libramdac_la_SOURCES = xf86RamDac.c xf86RamDacCmap.c \ >xf86Cursor.c xf86HWCurs.c IBM.c BT.c TI.c \ > xf86BitOrder.c > diff --git a/hw/xfree86/shadowfb/Makefile.am b/hw/xfree86/shadowfb/Makefile.am > index 02d2dd4..39c6610 100644 > --- a/hw/xfree86/shadowfb/Makefile.am > +++ b/hw/xfree86/shadowfb/Makefile.am > @@ -1,5 +1,5 @@ > module_LTLIBRARIES = libshadowfb.la > -libshadowfb_la_LDFLAGS = -avoid-version > +libshadowfb_la_LDFLAGS = -module -avoid-version > libshadowfb_la_SOURCES = sfbmodule.c shadow.c > > sdk_HEADERS = shadowfb.h > diff --git a/hw/xfree86/vbe/
Re: [PATCH 1/3] xfree86: fbdevhw: Remove unused include of pciaccess.h
Reviewed-by: Jamey Sharp On Wed, Sep 14, 2011 at 08:17:39PM -0500, Jeremy Huddleston wrote: > > Signed-off-by: Jeremy Huddleston > --- > hw/xfree86/fbdevhw/fbdevhw.h |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/hw/xfree86/fbdevhw/fbdevhw.h b/hw/xfree86/fbdevhw/fbdevhw.h > index bc46b9c..34870c2 100644 > --- a/hw/xfree86/fbdevhw/fbdevhw.h > +++ b/hw/xfree86/fbdevhw/fbdevhw.h > @@ -5,8 +5,6 @@ > #include "xf86str.h" > #include "colormapst.h" > > -#include > - > #define FBDEVHW_PACKED_PIXELS0 /* Packed Pixels > */ > #define FBDEVHW_PLANES 1 /* Non interleaved > planes */ > #define FBDEVHW_INTERLEAVED_PLANES 2 /* Interleaved planes */ > -- > 1.7.6.1 > > signature.asc Description: 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 libXi multitouch 2/4] Make users aware of the unstable nature of this development branch
On Sep 15, 2011, at 12:01 AM, Jamey Sharp wrote: > On Wed, Sep 14, 2011 at 10:33:55PM -0700, Chase Douglas wrote: >> +if ! test "x$UNSTABLE_LIB" = xyes; then >> +AC_MSG_ERROR([This branch contains elements which have not yet been >> finalised. When this branch is updated, you will probably need to recompile >> both the any clients using the library, and may experience crashes or >> undefined behaviour if you do not.]) >> +fi > > I think you meant to s/both the //? "...you will probably need to > recompile any clients using the library..." Hrm... yep, copy/paste error. I'll fix that up manually before applying if the patch is acceptable otherwise. -- Chase ___ 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 libXi multitouch 2/4] Make users aware of the unstable nature of this development branch
On Wed, Sep 14, 2011 at 10:33:55PM -0700, Chase Douglas wrote: > +if ! test "x$UNSTABLE_LIB" = xyes; then > +AC_MSG_ERROR([This branch contains elements which have not yet been > finalised. When this branch is updated, you will probably need to recompile > both the any clients using the library, and may experience crashes or > undefined behaviour if you do not.]) > +fi I think you meant to s/both the //? "...you will probably need to recompile any clients using the library..." Jamey signature.asc Description: 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
