Re: [PULL] fixes and clean ups for alpha
On Tue, Oct 13, 2009 at 10:22:09PM -0700, Jeremy Huddleston wrote: > > On Oct 13, 2009, at 20:22, Keith Packard wrote: > >> Excerpts from Matt Turner's message of Tue Oct 13 18:48:10 -0700 2009: >> >>> Actually before I sent the pull request I did `git pull origin >>> master` >>> to verify that there were no conflicts, and when there weren't I did >>> a >>> `git reset --hard HEAD^`. >> >> Ok, cool. >> >>> Is this OK? I'm not quite sure that a better way to do it is. >> >> There are a couple of options, but I'm not sure whether either is >> better. The first is to merge from origin/master, and the second is to >> rebase atop origin/master. Any one have strong feelings as to which of >> these three methods is 'best'? > > (IANAGE -- I Am Not A Git Expert) > > Well, as long as it's not actually pushed somewhere public, I think > rebasing onto origin/master will be more similar to the actual order in > which the changes would get applied when they're pulled into master. > > Of course this is all based on what I've been told and my shallow > understanding of git (man pages are easier to read with beer, btw...), > rebasing atop origin/master would be the wrong thing to do since this is > a published tree. Rebasing would rewrite history... and while rewriting > history would certainly be a good thing for my bank account, it would be > a bad thing for git. > > On a slightly more confusing point now... what do we do when a patch > gets denied. Say I have a patch that is in my published jeremyhu/master > and Keith decides that he doesn't like the way my code smells. What do I > do now? My branch is already published ... The only way I can have it > eventually merge back into master is by rewriting history... so does that > mean that we should rewrite history on our ~user/xserver trees, or is > there a better way to get around that? Yes, I know about git-revert, but > then that would be more ugliness in the history. A git revert has one advantage over a "make it disappear" rebase: it keeps the history. If I bump into this commit way down the track I know a) what you tried to solve and b) why you ended up doing it differently. (That is assuming you added an explanation for the revert). If you simply made the patch disappear then that information isn't available down the track. So this clean history is a short-term benefit but long term drawback. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] fixes and clean ups for alpha
On Oct 13, 2009, at 20:22, Keith Packard wrote: Excerpts from Matt Turner's message of Tue Oct 13 18:48:10 -0700 2009: Actually before I sent the pull request I did `git pull origin master` to verify that there were no conflicts, and when there weren't I did a `git reset --hard HEAD^`. Ok, cool. Is this OK? I'm not quite sure that a better way to do it is. There are a couple of options, but I'm not sure whether either is better. The first is to merge from origin/master, and the second is to rebase atop origin/master. Any one have strong feelings as to which of these three methods is 'best'? (IANAGE -- I Am Not A Git Expert) Well, as long as it's not actually pushed somewhere public, I think rebasing onto origin/master will be more similar to the actual order in which the changes would get applied when they're pulled into master. Of course this is all based on what I've been told and my shallow understanding of git (man pages are easier to read with beer, btw...), rebasing atop origin/master would be the wrong thing to do since this is a published tree. Rebasing would rewrite history... and while rewriting history would certainly be a good thing for my bank account, it would be a bad thing for git. On a slightly more confusing point now... what do we do when a patch gets denied. Say I have a patch that is in my published jeremyhu/ master and Keith decides that he doesn't like the way my code smells. What do I do now? My branch is already published ... The only way I can have it eventually merge back into master is by rewriting history... so does that mean that we should rewrite history on our ~user/xserver trees, or is there a better way to get around that? Yes, I know about git-revert, but then that would be more ugliness in the history. smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: git practices
On Oct 13, 2009, at 19:11, Peter Hutterer wrote: Note that while I'm writing this email there's a discussion on IRC about this anyway, so I don't know what the final verdict will be on that. Well, I'll need to read through my IRC logs when I get into the office tomorrow then. yes, but no. git isn't linear on a single line, you're missing the merge here. so origin/master is more like A B C D E F G H-M \1 2 3 4/ Ok... so I think my mental model is restructuring itself, thanks. I thought this was the huge "badness" which shows a bunch of "branch merged with branch " messages that get super messy because pull is essentially a fetch/merge. You do get them, yes. How much of a problem they're going to be in the futurue I don't know. They can be nasty when bisecting and confusing in the history. Yeah, bisecting and clean history is mainly what I'm concerned about. Check out how xorg-server-1.6-apple paralleled server-1.6-branch: git log --graph --pretty=oneline 7c16b68ab879f5b4b1aedfc6b2aadbe56193dd19...origin/xorg-server-1.6-apple (7c16b68ab879f5b4b1aedfc6b2aadbe56193dd19 was the server-1.6 branch from master ... I'm sure there's some clever way to say that in git syntas, but meh... I'm just no that cool.) For this branch, I just committed cherry-picks and merged origin/ server-1.6-branch ... there are a lot of long parallel tracks which would make bisecting problematic. I'm not even sure how bisection in git works without a linear model. My guess is that it just bisects along the main branch and sees the merge commit as a single $> git rebase -i origin/master reorder, cleanup, etc all changes since origin/master ... but we aren't actually tied to origin/master any more... this is what confuses me... the "pull" resulted in merging all changes in origin/master since our common ancestor into one commit, so we don't actually have origin/ master in our history. I think this should be the merge commit instead of origin/master. Yeah, that makes sense based on how I now understand things. origin/ master is not any more special than bond007/master in this scenario. Both are published and can't be altered. The merge commit just after each of those is essentially the union of the two and thus the most recent commit that needs to be unaltered. Need to test this again and fix the documentation. Note that due to the merge commit, both bond007/master and origin/master are in the history. Have a look at the master branch with tig, by default it shows all known refs in the history. e.g. in the current origin/master tree I can see daniels/master, alanc/master and mattst88/master (and of course my own one). Ah... interesting. git is certainly clever if not confusing... Thanks again, Jeremy smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] fixes and clean ups for alpha
Excerpts from Matt Turner's message of Tue Oct 13 18:48:10 -0700 2009: > Actually before I sent the pull request I did `git pull origin master` > to verify that there were no conflicts, and when there weren't I did a > `git reset --hard HEAD^`. Ok, cool. > Is this OK? I'm not quite sure that a better way to do it is. There are a couple of options, but I'm not sure whether either is better. The first is to merge from origin/master, and the second is to rebase atop origin/master. Any one have strong feelings as to which of these three methods is 'best'? -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: git practices
Note that while I'm writing this email there's a discussion on IRC about this anyway, so I don't know what the final verdict will be on that. On Tue, Oct 13, 2009 at 05:56:37PM -0700, Jeremy Huddleston wrote: > Thanks. That answers some questions, but I'm still left with others. > > The following commands give me puzzlement. Please correct my > misunderstandings. This is assuming the first case of push (my personal > tree has been merged into origin/master) > > Assuming: > origin/master has the following commits: A B C D E F G H 1 2 3 4 > bond007/master has the following commits: A B C D 1 2 3 4 > local branch matches bond007/master > > (ie, bond007/master has commits not in origin, and origin has some not > in bond007) > > $> git pull --rebase > > This fetches from the remote tree that the current branch is tracking... > most likely origin/master > > origin/master has the following commits: A B C D E F G H 1 2 3 4 > bond007/master has the following commits: A B C D 1 2 3 4 > local branch has the following commits : A B C D E F G H 1 2 3 4 yes, but no. git isn't linear on a single line, you're missing the merge here. so origin/master is more like A B C D E F G H-M \1 2 3 4/ One example - Alan's recent pull: $> git log --graph --pretty=oneline 24e640e1fa6cfb391..44efcdde501d54ca9 * 44efcdde501d54ca9c3e33ab5b1f699956fc3f9f Fix overlay detection when matching Xv adaptors across screens. * 68304215e25876ee639015969b4f07e1c9c515e0 Merge remote branch 'alanc/master' |\ | * 315aaef55750a863c08a16ad9120ffb76f9b48e0 Use $(AM_V_GEN) to silence more commands when AM_SILENT_RULES is active | * 2e294380b64b6362173d0590c4292f290e50af50 Migrate to xorg macros 1.3 & XORG_DEFAULT_OPTIONS | * 4b0911565d18b1aefca564315d0f1b9b4a17aa65 Add platform tests for Dtrace linker magic | * 8c51b886400c5962b31ff565771be1b01a3ca8fb configure: quote argument to m4_pattern_forbid | * 6ee61578ddb9f880ef12bbe9c3671d7dd53f2809 Remove shave now that automake-1.11 has AM_SILENT_RULES | * d5d960f57834f16164457dab2e80290717dbf2cd render: Fix clip region translation in miClipPictureSrc(). | * d2118c8ca94fc7bcb8e0de547e63cf022f53a8a9 xfree86: remove log-spamming DebugF | * bf116057c7efd43c247c93f2f5d733a5db857cc9 Require libXtst >= 1.0.99.2 and libdmx >= 1.0.99.1 | * 1a2dde3335864abfbbc133dbc709f564272dd540 Set XQUARTZ to no on non-Darwin OS'es * 6676f49e34f8db7ef5767a6dbf6c2a4d2087f79c configure: quote argument to m4_pattern_forbid * a0363bf7b135d816e73849c91fa53d98fd6072d1 Remove shave now that automake-1.11 has AM_SILENT_RULES * cbc886a3513079c084fb7ce47b87c3e5bba19f3f render: Fix clip region translation in miClipPictureSrc(). * bd7430a32e63df8cd60352764744076448ee623f xfree86: remove log-spamming DebugF * c629e0fc50dfaffaa40a56709da7f035c289fed2 Require libXtst >= 1.0.99.2 and libdmx >= 1.0.99.1 Rebasing from 315aaef (last on alan's branch) to master is fast-forward. Anything you apply on top of that can then be rebased again. The rest of your comments were based on the linear history assumption, so I'll skip them :) > As for the second case (it has not been pulled into master): > > Assuming: > origin/master has the following commits: A B C D E F G H > bond007/master has the following commits: A B C D 1 2 3 4 > local branch matches bond007/master > > $> git pull origin # if you need to sync with master > > origin/master has the following commits: A B C D E F G H > bond007/master has the following commits: A B C D 1 2 3 4 > local branch has the following commits: A B C D 1 2 3 4 EFGH > > I thought this was the huge "badness" which shows a bunch of "branch > merged with branch " messages that get super messy because pull > is essentially a fetch/merge. You do get them, yes. How much of a problem they're going to be in the futurue I don't know. They can be nasty when bisecting and confusing in the history. > $> git am -s > # test > > commit patches locally: > origin/master has the following commits: A B C D E F G H > bond007/master has the following commits: A B C D 1 2 3 4 > local branch has the following commits : A B C D 1 2 3 4 EFGH 5 6 7 8 > > $> git rebase -i origin/master > > reorder, cleanup, etc all changes since origin/master ... but we aren't > actually tied to origin/master any more... this is what confuses me... > the "pull" resulted in merging all changes in origin/master since our > common ancestor into one commit, so we don't actually have origin/master > in our history. I think this should be the merge commit instead of origin/master. Need to test this again and fix the documentation. Note that due to the merge commit, both bond007/master and origin/master are in the history. Have a look at the master branch with tig, by default it shows all known refs in the history. e.g. in the current origin/master tree I can see daniels/master, alanc/master and mattst88/master (and of course my own one). Cheers, Peter ___ xorg-
Re: [PULL] fixes and clean ups for alpha
On 10/13/2009 09:45 PM, Daniel Stone wrote: > Hi, > > On Tue, Oct 13, 2009 at 09:24:49PM -0400, Matt Turner wrote: > >> Please pull these changes into master. I've gotten confirmation from >> multiple users that they fix the xserver on alpha. >> > Would these be useful for 1.6 as well? It looks like there might well be > some use in 1.6.6, if we can fix XACE (Eamon?), XKB detectable > autorepeat, and Alpha. > > I do have some stuff I need to go in to 1.6. The tree at fdo/~ewalsh/xserver has the patches for master, but I need to backport for 1.6 since it touches some XI2 stuff. I'll get everything cleaned up and send the pull request tomorrow. -- Eamon Walsh National Security Agency ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] fixes and clean ups for alpha
On Tue, Oct 13, 2009 at 9:45 PM, Daniel Stone wrote: > Hi, > > On Tue, Oct 13, 2009 at 09:24:49PM -0400, Matt Turner wrote: >> Please pull these changes into master. I've gotten confirmation from >> multiple users that they fix the xserver on alpha. > > Would these be useful for 1.6 as well? It looks like there might well be > some use in 1.6.6, if we can fix XACE (Eamon?), XKB detectable > autorepeat, and Alpha. > > Cheers, > Daniel Yes, definitely. But again, I'm not 100% clear on the protocol for doing this. Matt ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] fixes and clean ups for alpha
Thanks. On Tue, Oct 13, 2009 at 9:42 PM, Keith Packard wrote: > Excerpts from Matt Turner's message of Tue Oct 13 18:24:49 -0700 2009: >> Hi Keith, >> Please pull these changes into master. I've gotten confirmation from >> multiple users that they fix the xserver on alpha. > > Looks like it worked, but for future reference, it's probably best to > rebase your changes to something closer to master before submitting a > PULL request. Otherwise you risk a merge conflict, which I'll just > bounce. Sure. Actually before I sent the pull request I did `git pull origin master` to verify that there were no conflicts, and when there weren't I did a `git reset --hard HEAD^`. Is this OK? I'm not quite sure that a better way to do it is. Matt ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] fixes and clean ups for alpha
Hi, On Tue, Oct 13, 2009 at 09:24:49PM -0400, Matt Turner wrote: > Please pull these changes into master. I've gotten confirmation from > multiple users that they fix the xserver on alpha. Would these be useful for 1.6 as well? It looks like there might well be some use in 1.6.6, if we can fix XACE (Eamon?), XKB detectable autorepeat, and Alpha. Cheers, Daniel pgpdexhTuv66k.pgp Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] fixes and clean ups for alpha
Excerpts from Matt Turner's message of Tue Oct 13 18:24:49 -0700 2009: > Hi Keith, > Please pull these changes into master. I've gotten confirmation from > multiple users that they fix the xserver on alpha. Looks like it worked, but for future reference, it's probably best to rebase your changes to something closer to master before submitting a PULL request. Otherwise you risk a merge conflict, which I'll just bounce. -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:libfontenc] Use fontutil macros to determine default font path
I've had essentially the same thing sitting in my libfontenc tree, as part
of my development & testing of the font-util macros, but hadn't
commited/pushed it yet - I'll do that now. Thanks for the reminder.
-alan-
Yaakov (Cygwin/X) wrote:
> From: Yaakov Selkowitz
>
> With font-util 1.1, the default font path has changed, and macros are
> provided to determine the configured path. libfontenc should use these
> macros as well to provide a default which is more likely to be correct.
>
> This adds a build-time (or at least an autoconf/autogen time) dependency
> on font-util.
>
> Signed-off-by: Yaakov Selkowitz
> ---
> configure.ac | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index fc28ef9..1edb4c3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -30,6 +30,10 @@ AM_MAINTAINER_MODE
> # Require xorg-macros: XORG_CWARNFLAGS, XORG_CHANGELOG, XORG_WITH_LINT
> m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or
> later before running autoconf/autogen])])
> XORG_MACROS_VERSION(1.2)
> +
> +m4_ifndef([XORG_FONT_MACROS_VERSION], [AC_FATAL([must install font-util 1.1
> or later before running autoconf/autogen])])
> +XORG_FONT_MACROS_VERSION(1.1)
> +
> AM_CONFIG_HEADER(config.h)
>
> # Check for progs
> @@ -37,11 +41,7 @@ AC_PROG_CC
> AC_PROG_LIBTOOL
> XORG_CWARNFLAGS
>
> -encodingsdir=${libdir}/X11/fonts/encodings
> -AC_ARG_WITH(encodingsdir, AC_HELP_STRING([--with-encodingsdir=],
> - [Path to font encodings]), [encodingsdir="$withval"])
> -ENCODINGSDIR="$encodingsdir"
> -AC_SUBST(ENCODINGSDIR)
> +XORG_FONTSUBDIR([ENCODINGSDIR],[encodingsdir],[encodings])
>
> # zlib
>
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:xserver] Use fontutil macros to determine default font path
Thanks - I was planning to do this once the fontutil macros had gotten out there
and distributed. I'd also like to see a check like the one in app/xfs for
/etc/X11/fontpath.d and using that as a catalogue: entry if it exists, but that
can be done as a separate patch.
Also I've been using m4_fatal instead of AC_FATAL, as per a discussion a while
ago that it stops autoconf from generating the bad configure, instead of letting
configure get built if it might not be usable.
-alan-
Yaakov (Cygwin/X) wrote:
> From: Yaakov Selkowitz
>
> With font-util 1.1, the default font path has changed, and macros are
> provided to determine the configured path. xserver should use these
> macros as well to provide a default which is more likely to be correct.
>
> This adds a build-time (or at least an autoconf/autogen time) dependency
> on font-util, and changes the --with-fontdir argument to --with-fontrootdir.
>
> Signed-off-by: Yaakov Selkowitz
> ---
> configure.ac | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index fa454fa..7c967d0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -36,6 +36,9 @@ AM_MAINTAINER_MODE
> m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or
> later before running autoconf/autogen])])
> XORG_MACROS_VERSION(1.3)
>
> +m4_ifndef([XORG_FONT_MACROS_VERSION], [AC_FATAL([must install fontutil 1.1
> or later before running autoconf/autogen])])
> +XORG_FONT_MACROS_VERSION(1.1)
> +
> dnl this gets generated by autoheader, and thus contains all the defines. we
> dnl don't ever actually use it, internally.
> AC_CONFIG_HEADERS(include/do-not-use-config.h)
> @@ -74,6 +77,7 @@ XORG_PROG_RAWCPP
> AC_PATH_PROG(SED,sed)
>
> XORG_DEFAULT_OPTIONS
> +XORG_FONTROOTDIR
> # Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
> # easier overrides at build time.
> XSERVER_CFLAGS='$(CWARNFLAGS)'
> @@ -487,10 +491,7 @@ AC_ARG_WITH(os-vendor,
> AS_HELP_STRING([--with-os-vendor=OSVENDOR], [Name o
> AC_ARG_WITH(builderstring,
> AS_HELP_STRING([--with-builderstring=BUILDERSTRING], [Additional builder
> string]),
> [ BUILDERSTRING="$withval" ]
> [ ])
> -AC_ARG_WITH(fontdir, AS_HELP_STRING([--with-fontdir=FONTDIR], [Path
> to top level dir where fonts are installed (default: ${libdir}/X11/fonts)]),
> -[ FONTDIR="$withval" ],
> -[ FONTDIR="${libdir}/X11/fonts" ])
> -DEFAULT_FONT_PATH="${FONTDIR}/misc/,${FONTDIR}/TTF/,${FONTDIR}/OTF,${FONTDIR}/Type1/,${FONTDIR}/100dpi/,${FONTDIR}/75dpi/"
> +DEFAULT_FONT_PATH="${FONTROOTDIR}/misc/,${FONTROOTDIR}/TTF/,${FONTROOTDIR}/OTF/,${FONTROOTDIR}/Type1/,${FONTROOTDIR}/100dpi/,${FONTROOTDIR}/75dpi/"
> case $host_os in
> darwin*)
> DEFAULT_FONT_PATH="${DEFAULT_FONT_PATH},/Library/Fonts,/System/Library/Fonts"
> ;;
> esac
> @@ -1180,7 +1181,7 @@ fi
> AC_DEFINE_DIR(COMPILEDDEFAULTFONTPATH, FONTPATH, [Default font path])
> AC_DEFINE_DIR(PCI_TXT_IDS_PATH, PCI_TXT_IDS_DIR, [Default PCI text file ID
> path])
> AC_DEFINE_DIR(SERVER_MISC_CONFIG_PATH, SERVERCONFIG, [Server miscellaneous
> config path])
> -AC_DEFINE_DIR(BASE_FONT_PATH, FONTDIR, [Default base font path])
> +AC_DEFINE_DIR(BASE_FONT_PATH, FONTROOTDIR, [Default base font path])
> AC_DEFINE_DIR(DRI_DRIVER_PATH, DRI_DRIVER_PATH, [Default DRI driver path])
> AC_DEFINE_UNQUOTED(XVENDORNAME, ["$VENDOR_NAME"], [Vendor name])
> AC_DEFINE_UNQUOTED(XVENDORNAMESHORT, ["$VENDOR_NAME_SHORT"], [Short vendor
> name])
--
-Alan Coopersmith- alan.coopersm...@sun.com
Sun Microsystems, Inc. - X Window System Engineering
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] fixes and clean ups for alpha
Hi Keith, Please pull these changes into master. I've gotten confirmation from multiple users that they fix the xserver on alpha. Thanks, Matt The following changes since commit 6676f49e34f8db7ef5767a6dbf6c2a4d2087f79c: Julien Cristau (1): configure: quote argument to m4_pattern_forbid are available in the git repository at: git://anongit.freedesktop.org/~mattst88/xserver master Matt Turner (3): Fix breakage on alpha caused by c7680befe5ae [alpha] don't return from void functions [alpha] assume we have __NR_pciconfig_iobase Michael Cree (1): Fix undefined symbols on alpha Peter Hutterer (1): Revert "alpha: kill xf86SlowBCopyToBus and xf86SlowBCopyFromBus" hw/xfree86/common/compiler.h | 16 +++ hw/xfree86/os-support/linux/lnx_axp.c| 16 +++ hw/xfree86/os-support/linux/lnx_ev56.c | 18 +--- hw/xfree86/os-support/misc/SlowBcopy.c | 68 ++ hw/xfree86/os-support/shared/bios_mmap.c |2 +- hw/xfree86/vgahw/vgaHW.c | 16 6 files changed, 111 insertions(+), 25 deletions(-) ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH:xserver] Use fontutil macros to determine default font path
From: Yaakov Selkowitz
With font-util 1.1, the default font path has changed, and macros are
provided to determine the configured path. xserver should use these
macros as well to provide a default which is more likely to be correct.
This adds a build-time (or at least an autoconf/autogen time) dependency
on font-util, and changes the --with-fontdir argument to --with-fontrootdir.
Signed-off-by: Yaakov Selkowitz
---
configure.ac | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index fa454fa..7c967d0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,6 +36,9 @@ AM_MAINTAINER_MODE
m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or
later before running autoconf/autogen])])
XORG_MACROS_VERSION(1.3)
+m4_ifndef([XORG_FONT_MACROS_VERSION], [AC_FATAL([must install fontutil 1.1 or
later before running autoconf/autogen])])
+XORG_FONT_MACROS_VERSION(1.1)
+
dnl this gets generated by autoheader, and thus contains all the defines. we
dnl don't ever actually use it, internally.
AC_CONFIG_HEADERS(include/do-not-use-config.h)
@@ -74,6 +77,7 @@ XORG_PROG_RAWCPP
AC_PATH_PROG(SED,sed)
XORG_DEFAULT_OPTIONS
+XORG_FONTROOTDIR
# Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow
# easier overrides at build time.
XSERVER_CFLAGS='$(CWARNFLAGS)'
@@ -487,10 +491,7 @@ AC_ARG_WITH(os-vendor,
AS_HELP_STRING([--with-os-vendor=OSVENDOR], [Name o
AC_ARG_WITH(builderstring,
AS_HELP_STRING([--with-builderstring=BUILDERSTRING], [Additional builder
string]),
[ BUILDERSTRING="$withval" ]
[ ])
-AC_ARG_WITH(fontdir, AS_HELP_STRING([--with-fontdir=FONTDIR], [Path to
top level dir where fonts are installed (default: ${libdir}/X11/fonts)]),
-[ FONTDIR="$withval" ],
-[ FONTDIR="${libdir}/X11/fonts" ])
-DEFAULT_FONT_PATH="${FONTDIR}/misc/,${FONTDIR}/TTF/,${FONTDIR}/OTF,${FONTDIR}/Type1/,${FONTDIR}/100dpi/,${FONTDIR}/75dpi/"
+DEFAULT_FONT_PATH="${FONTROOTDIR}/misc/,${FONTROOTDIR}/TTF/,${FONTROOTDIR}/OTF/,${FONTROOTDIR}/Type1/,${FONTROOTDIR}/100dpi/,${FONTROOTDIR}/75dpi/"
case $host_os in
darwin*)
DEFAULT_FONT_PATH="${DEFAULT_FONT_PATH},/Library/Fonts,/System/Library/Fonts" ;;
esac
@@ -1180,7 +1181,7 @@ fi
AC_DEFINE_DIR(COMPILEDDEFAULTFONTPATH, FONTPATH, [Default font path])
AC_DEFINE_DIR(PCI_TXT_IDS_PATH, PCI_TXT_IDS_DIR, [Default PCI text file ID
path])
AC_DEFINE_DIR(SERVER_MISC_CONFIG_PATH, SERVERCONFIG, [Server miscellaneous
config path])
-AC_DEFINE_DIR(BASE_FONT_PATH, FONTDIR, [Default base font path])
+AC_DEFINE_DIR(BASE_FONT_PATH, FONTROOTDIR, [Default base font path])
AC_DEFINE_DIR(DRI_DRIVER_PATH, DRI_DRIVER_PATH, [Default DRI driver path])
AC_DEFINE_UNQUOTED(XVENDORNAME, ["$VENDOR_NAME"], [Vendor name])
AC_DEFINE_UNQUOTED(XVENDORNAMESHORT, ["$VENDOR_NAME_SHORT"], [Short vendor
name])
--
1.6.4.2
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH:xserver] dolt: add Cygwin to supported platforms
From: Yaakov Selkowitz Signed-off-by: Yaakov Selkowitz --- m4/dolt.m4 |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/m4/dolt.m4 b/m4/dolt.m4 index 1109bdb..7c62b6c 100644 --- a/m4/dolt.m4 +++ b/m4/dolt.m4 @@ -26,6 +26,9 @@ i?86-*-linux*|x86_64-*-linux*|powerpc-*-linux* \ |amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*) pic_options='-fPIC' ;; +i?86-pc-cygwin*) +pic_options='-DDLL_EXPORT' +;; i?86-apple-darwin*) pic_options='-fno-common' ;; -- 1.6.4.2 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH:libfontenc] Use fontutil macros to determine default font path
From: Yaakov Selkowitz
With font-util 1.1, the default font path has changed, and macros are
provided to determine the configured path. libfontenc should use these
macros as well to provide a default which is more likely to be correct.
This adds a build-time (or at least an autoconf/autogen time) dependency
on font-util.
Signed-off-by: Yaakov Selkowitz
---
configure.ac | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index fc28ef9..1edb4c3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -30,6 +30,10 @@ AM_MAINTAINER_MODE
# Require xorg-macros: XORG_CWARNFLAGS, XORG_CHANGELOG, XORG_WITH_LINT
m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.2 or
later before running autoconf/autogen])])
XORG_MACROS_VERSION(1.2)
+
+m4_ifndef([XORG_FONT_MACROS_VERSION], [AC_FATAL([must install font-util 1.1 or
later before running autoconf/autogen])])
+XORG_FONT_MACROS_VERSION(1.1)
+
AM_CONFIG_HEADER(config.h)
# Check for progs
@@ -37,11 +41,7 @@ AC_PROG_CC
AC_PROG_LIBTOOL
XORG_CWARNFLAGS
-encodingsdir=${libdir}/X11/fonts/encodings
-AC_ARG_WITH(encodingsdir, AC_HELP_STRING([--with-encodingsdir=],
- [Path to font encodings]), [encodingsdir="$withval"])
-ENCODINGSDIR="$encodingsdir"
-AC_SUBST(ENCODINGSDIR)
+XORG_FONTSUBDIR([ENCODINGSDIR],[encodingsdir],[encodings])
# zlib
--
1.6.4.2
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Cygwin GCC does not use visibility attributes
From: Yaakov Selkowitz
Cygwin's gcc4 accepts visibility attributes but does actually use them,
generating tons of warnings that they are not supported.
Signed-off-by: Yaakov Selkowitz
---
configure.ac |2 +-
pixman/pixman-compiler.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index c548174..6db240f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -143,7 +143,7 @@ dnl -fvisibility stuff
have_gcc4=no
AC_MSG_CHECKING(for -fvisibility)
AC_COMPILE_IFELSE([
-#if defined(__GNUC__) && (__GNUC__ >= 4)
+#if defined(__GNUC__) && (__GNUC__ >= 4) && !defined(__CYGWIN__)
#else
error Need GCC 4.0 for visibility
#endif
diff --git a/pixman/pixman-compiler.h b/pixman/pixman-compiler.h
index 9647dbb..37dcf72 100644
--- a/pixman/pixman-compiler.h
+++ b/pixman/pixman-compiler.h
@@ -60,7 +60,7 @@
#endif
/* GCC visibility */
-#if defined(__GNUC__) && __GNUC__ >= 4
+#if defined(__GNUC__) && __GNUC__ >= 4 && !defined(__CYGWIN__)
# define PIXMAN_EXPORT __attribute__ ((visibility("default")))
/* Sun Studio 8 visibility */
#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
--
1.6.4.2
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: git practices
Thanks. That answers some questions, but I'm still left with others. The following commands give me puzzlement. Please correct my misunderstandings. This is assuming the first case of push (my personal tree has been merged into origin/master) Assuming: origin/master has the following commits: A B C D E F G H 1 2 3 4 bond007/master has the following commits: A B C D 1 2 3 4 local branch matches bond007/master (ie, bond007/master has commits not in origin, and origin has some not in bond007) $> git pull --rebase This fetches from the remote tree that the current branch is tracking... most likely origin/master origin/master has the following commits: A B C D E F G H 1 2 3 4 bond007/master has the following commits: A B C D 1 2 3 4 local branch has the following commits : A B C D E F G H 1 2 3 4 $> git am -s # test commit patches locally: origin/master has the following commits: A B C D E F G H 1 2 3 4 bond007/master has the following commits: A B C D 1 2 3 4 local branch has the following commits : A B C D E F G H 1 2 3 4 5 6 7 8 $> git rebase -i origin/master # if you need to reshuffle something reorder, merge, etc all changes since origin/master origin/master has the following commits: A B C D E F G H 1 2 3 4 bond007/master has the following commits: A B C D 1 2 3 4 local branch has the following commits : A B C D E F G H 1 2 3 4 58 7 6 $> git push bond007 master Push the current branch to bond007/master ... This seems wrong to me. The current branch is no longer a fast-forward of bond007/master. We'd need to force it via (IIRC): $> git push bond007 +master but then that would rewrite history (which is bad) ... so... ? -- As for the second case (it has not been pulled into master): Assuming: origin/master has the following commits: A B C D E F G H bond007/master has the following commits: A B C D 1 2 3 4 local branch matches bond007/master $> git pull origin # if you need to sync with master origin/master has the following commits: A B C D E F G H bond007/master has the following commits: A B C D 1 2 3 4 local branch has the following commits: A B C D 1 2 3 4 EFGH I thought this was the huge "badness" which shows a bunch of "branch merged with branch " messages that get super messy because pull is essentially a fetch/merge. $> git am -s # test commit patches locally: origin/master has the following commits: A B C D E F G H bond007/master has the following commits: A B C D 1 2 3 4 local branch has the following commits : A B C D 1 2 3 4 EFGH 5 6 7 8 $> git rebase -i origin/master reorder, cleanup, etc all changes since origin/master ... but we aren't actually tied to origin/master any more... this is what confuses me... the "pull" resulted in merging all changes in origin/ master since our common ancestor into one commit, so we don't actually have origin/master in our history. Thanks for clearing this up, Jeremy On Oct 13, 2009, at 16:45, Peter Hutterer wrote: On Tue, Oct 13, 2009 at 04:01:19PM -0700, Jeremy Huddleston wrote: On Oct 13, 2009, at 14:48, Peter Hutterer wrote: On Tue, Oct 13, 2009 at 12:08:53PM -0700, Jeremy Huddleston wrote: I'm still holding off branching from master or creating my own xserver git because I want to read your promised "best practices", so I do it correctly. Have you gotten around to starting that up? http://www.x.org/wiki/XServer is what we have so far. Let me know what's missing and I'll add it. Ok, thanks. Some questions/confusion from someone who isn't a git- expert: Thanks, I tried to merge your comments into the above page, please have a look again. See the diff here http://www.x.org/wiki/XServer? action=diff --- In "Scooping", Shouldn't we be using 'git fetch origin; git rebase origin/master' rather than 'git pull origin'? Is 'git pull --rebase' the same thing as 'git fetch; git rebase ___'? yes, 'git pull --rebase origin' is the same as 'git fetch origin; git rebase origin/master'. you can set up hooks for each repo to tell it what it means when you don't specify the remote but I've gotten used to always supplying the remote. IIRC you can also set git up that git pull --rebase rebases a diffent branch but I don't know how to do that - never needed to. I guess I'm just confused about pull. please look, I hope I explained now when to rebase and when to pull but I didn't add a full documentation on pull/rebase - this isn't the right page for it. --- How can I get email sent for pushes to my personal git? (eg: I'd like to have mail sent to xquartz-chan...@lists.macosforge.org) in your fdo repository, edit .git/hooks/update. (look at /srv/anongit.freedesktop.org/git/xorg/xserver.git/hooks/ update on annarchy for the xorg-commits email generation) --- When I'm on my local branch, how do I make it so master pushes to my tree on anarchy? Assume I've done: git clone ssh://git.freedesktop.org/git/xorg/xserver cd xserver git re
[PATCH 3/3] Provide _Xsetlocale compat wrappers on Cygwin
From: Yaakov Selkowitz
Previous versions of Cygwin did not have proper locale support, so Cygwin/X
defined X_LOCALE, using _Xsetlocale instead. Cygwin 1.7 has added locale
support, but we can't remove the _Xsetlocale entry point without breaking
ABI.
Signed-off-by: Yaakov Selkowitz
---
src/SetLocale.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/SetLocale.c b/src/SetLocale.c
index 0155777..a19baa9 100644
--- a/src/SetLocale.c
+++ b/src/SetLocale.c
@@ -121,7 +121,7 @@ _Xsetlocale(
#else /* X_LOCALE */
-#ifdef __APPLE__
+#if defined(__APPLE__) || defined(__CYGWIN__)
char *
_Xsetlocale(
int category,
@@ -130,7 +130,7 @@ _Xsetlocale(
{
return setlocale(category, name);
}
-#endif /* __APPLE__ */
+#endif /* __APPLE__ || __CYGWIN__ */
/*
* _XlcMapOSLocaleName is an implementation dependent routine that derives
--
1.6.4.2
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/3] Fix Cygwin compile of xcb_io.c
From: Yaakov Selkowitz
Per POSIX, struct timeval is defined in . Compilation on Cygwin
explicitely requires this #include.
Signed-off-by: Yaakov Selkowitz
---
src/xcb_io.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/xcb_io.c b/src/xcb_io.c
index 4f0159c..7292b37 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
static void return_socket(void *closure)
{
--
1.6.4.2
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/3] dolt: add Cygwin to supported platforms
From: Yaakov Selkowitz Signed-off-by: Yaakov Selkowitz --- acinclude.m4 |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/acinclude.m4 b/acinclude.m4 index 1485a8c..922145f 100644 --- a/acinclude.m4 +++ b/acinclude.m4 @@ -76,6 +76,9 @@ i?86-*-linux*|x86_64-*-linux*|powerpc-*-linux* \ |amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*) pic_options='-fPIC' ;; +i?86-pc-cygwin*) +pic_options='-DDLL_EXPORT' +;; i?86-apple-darwin*) pic_options='-fno-common' ;; -- 1.6.4.2 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 0/3] Xlib Cygwin patches
From: Yaakov Selkowitz These three patches are required to fix libX11-1.3 on Cygwin. Yaakov Selkowitz (3): dolt: add Cygwin to supported platforms Fix Cygwin compile of xcb_io.c Provide _Xsetlocale compat wrappers on Cygwin acinclude.m4|3 +++ src/SetLocale.c |4 ++-- src/xcb_io.c|1 + 3 files changed, 6 insertions(+), 2 deletions(-) ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] DRI2: Report the correct extension minor version
On Tue, Oct 13, 2009 at 04:26:26PM -0700, Aaron Plattner wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Signed-off-by: Aaron Plattner
> - ---
> hw/xfree86/dri2/dri2ext.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
> index 6c14578..dc07b47 100644
> - --- a/hw/xfree86/dri2/dri2ext.c
> +++ b/hw/xfree86/dri2/dri2ext.c
> @@ -81,7 +81,7 @@ ProcDRI2QueryVersion(ClientPtr client)
> rep.length = 0;
> rep.sequenceNumber = client->sequence;
> rep.majorVersion = SERVER_DRI2_MAJOR_VERSION;
> - -rep.minorVersion = SERVER_DRI2_MAJOR_VERSION;
> +rep.minorVersion = SERVER_DRI2_MINOR_VERSION;
>
> if (client->swapped) {
> swaps(&rep.sequenceNumber, n);
> - --
> 1.6.0.4
Reviewed-by: Peter Hutterer
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: git practices
On Tue, Oct 13, 2009 at 04:01:19PM -0700, Jeremy Huddleston wrote: > On Oct 13, 2009, at 14:48, Peter Hutterer wrote: > >> On Tue, Oct 13, 2009 at 12:08:53PM -0700, Jeremy Huddleston wrote: >>> I'm still holding off branching from master or creating my own >>> xserver >>> git because I want to read your promised "best practices", so I do it >>> correctly. Have you gotten around to starting that up? >> >> >> http://www.x.org/wiki/XServer >> is what we have so far. Let me know what's missing and I'll add it. > Ok, thanks. Some questions/confusion from someone who isn't a git- > expert: Thanks, I tried to merge your comments into the above page, please have a look again. See the diff here http://www.x.org/wiki/XServer?action=diff > --- > > In "Scooping", Shouldn't we be using 'git fetch origin; git rebase > origin/master' rather than 'git pull origin'? > > Is 'git pull --rebase' the same thing as 'git fetch; git rebase > ___'? yes, 'git pull --rebase origin' is the same as 'git fetch origin; git rebase origin/master'. you can set up hooks for each repo to tell it what it means when you don't specify the remote but I've gotten used to always supplying the remote. IIRC you can also set git up that git pull --rebase rebases a diffent branch but I don't know how to do that - never needed to. > I guess I'm just confused about pull. please look, I hope I explained now when to rebase and when to pull but I didn't add a full documentation on pull/rebase - this isn't the right page for it. > --- > > How can I get email sent for pushes to my personal git? (eg: I'd like > to have mail sent to xquartz-chan...@lists.macosforge.org) in your fdo repository, edit .git/hooks/update. (look at /srv/anongit.freedesktop.org/git/xorg/xserver.git/hooks/update on annarchy for the xorg-commits email generation) > --- > > When I'm on my local branch, how do I make it so master pushes to my > tree on anarchy? Assume I've done: > > git clone ssh://git.freedesktop.org/git/xorg/xserver > cd xserver > git remote jeremyhu ssh://git.freedesktop.org/~jeremyhu/xserver.git ^^ git remote add > git push jeremyhu master > # edit some files > git commit -a > git push # will this send my local master to origin/master or jeremyhu/ > master? How can I make it use jeremyhu/master if it's still origin/ > master? push without a remote always pushes to origin (git.freedesktop.org) IIRC in older versions of git that even pushed all local branches to the remote, hence why I started always using explicit remotes and branches. so in the future you should always use git push , pushes your local branch to remote/branch. the safest way is to clone origin anongit, that way you can't accidentally push into it (though that stops you from pushing into 1.7-nominations as well of course). so, back to start - does the wiki page answer the questions now? Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] DRI2: Report the correct extension minor version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Signed-off-by: Aaron Plattner
- ---
hw/xfree86/dri2/dri2ext.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/dri2/dri2ext.c b/hw/xfree86/dri2/dri2ext.c
index 6c14578..dc07b47 100644
- --- a/hw/xfree86/dri2/dri2ext.c
+++ b/hw/xfree86/dri2/dri2ext.c
@@ -81,7 +81,7 @@ ProcDRI2QueryVersion(ClientPtr client)
rep.length = 0;
rep.sequenceNumber = client->sequence;
rep.majorVersion = SERVER_DRI2_MAJOR_VERSION;
- -rep.minorVersion = SERVER_DRI2_MAJOR_VERSION;
+rep.minorVersion = SERVER_DRI2_MINOR_VERSION;
if (client->swapped) {
swaps(&rep.sequenceNumber, n);
- --
1.6.0.4
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iQEcBAEBAgAGBQJK1QyiAAoJEHYgpP6LHaLQpfEH/Av37kppF9biucvIOoMhbH3U
n2faazViu8BTi5F8E2KJZOKak/qi7hBkDmJDnsUDut6QSei9jnxxJQsra5BS/4x9
c2PsSNrQf44dYhjHpJ+9RCvzASS9zWiKAioMUdLEzNBNXMjDEcI/nS9Te19jxPbQ
XKQSD/i4NsnHXq1hQ1bMXVBFTSyKzwR9FGK27g+yyWpAqGS9cq3veq6SrFESidpo
FRPtFRiE/OGLru+wgE2E0fh6UoM3gFokuIIFD2EjeFBziEzVvKPO+kI2tcJI1Jlu
BcWUZjYBlGMs6FlcPeaKTBguCDyKm2UORCE0M/Pwvg7iSr1EXzLDu6/myJVNPiU=
=OC23
-END PGP SIGNATURE-
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: git practices
On Oct 13, 2009, at 14:48, Peter Hutterer wrote: On Tue, Oct 13, 2009 at 12:08:53PM -0700, Jeremy Huddleston wrote: I'm still holding off branching from master or creating my own xserver git because I want to read your promised "best practices", so I do it correctly. Have you gotten around to starting that up? http://www.x.org/wiki/XServer is what we have so far. Let me know what's missing and I'll add it. Ok, thanks. Some questions/confusion from someone who isn't a git- expert: In "Maintainers", it's not clear that the directory you do "git remote ... ; git push fdo master" is your checked out xserver.git ... perhaps add: git clone ssh://git.freedesktop.org/git/xorg/xserver cd xserver --- In "Maintainers", why are you doing "git pull master"? Should that be "git pull --rebase master"? I thought you should never, never, never use "git pull" ... --- In "Scooping up patches," you do: git push bond007 master but in "Maintainers", you do: git push fdo master Where did "bond007" come from? Should that have been "fdo" to match the git remote above in "Maintainers"? --- In "Scooping", Shouldn't we be using 'git fetch origin; git rebase origin/master' rather than 'git pull origin'? Is 'git pull --rebase' the same thing as 'git fetch; git rebase ___'? I guess I'm just confused about pull. --- How can I get email sent for pushes to my personal git? (eg: I'd like to have mail sent to xquartz-chan...@lists.macosforge.org) --- When I'm on my local branch, how do I make it so master pushes to my tree on anarchy? Assume I've done: git clone ssh://git.freedesktop.org/git/xorg/xserver cd xserver git remote jeremyhu ssh://git.freedesktop.org/~jeremyhu/xserver.git git push jeremyhu master # edit some files git commit -a git push # will this send my local master to origin/master or jeremyhu/ master? How can I make it use jeremyhu/master if it's still origin/ master? smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xproto: Cygwin GCC does not support visibility attributes
From: Yaakov Selkowitz
---
Xfuncproto.h.in |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Xfuncproto.h.in b/Xfuncproto.h.in
index 0843491..afdd95b 100644
--- a/Xfuncproto.h.in
+++ b/Xfuncproto.h.in
@@ -83,7 +83,7 @@ in this Software without prior written authorization from The
Open Group.
# define _X_ATTRIBUTE_PRINTF(x,y)
#endif /* GNUC >= 4 */
-#if defined(__GNUC__) && (__GNUC__ >= 4)
+#if defined(__GNUC__) && (__GNUC__ >= 4) && !defined(__CYGWIN__)
# define _X_EXPORT __attribute__((visibility("default")))
# define _X_HIDDEN __attribute__((visibility("hidden")))
# define _X_INTERNAL__attribute__((visibility("internal")))
--
1.6.4.2
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: cherry-pick to master
Excerpts from Jeremy Huddleston's message of Tue Oct 13 13:34:52 -0700 2009: > No, I actually tested these on master and am living on master... I've cherry-picked these and pushed master out; let's figure out how to avoid that in future; master should never contain cherry picked patches :-) -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Rootless: src drawable window can now be NULL
Excerpts from Jeremy Huddleston's message of Tue Oct 13 17:25:33 +0100 2009: > That looks like a sane enough sanity check... but why was > pSrc->pDrawable NULL in the first place? RenderSources, i.e. gradients and solid fills, do not have an associated Drawable. -ickle -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: cherry-pick to master
Excerpts from Jeremy Huddleston's message of Tue Oct 13 13:34:52 -0700 2009: > > but since I can't commit to master by policy (merge to master from > feature branches), and I don't have an apple feature branch tracking > master (since I'm waiting for Peter's documentation on the best > practices for that), the only place I could put them in git for you > was on my 1.7 branch... but I assure you I'm actually using them on > master myself. Ok, so the other 'official' way to get patches into master is to just post them to the list using git format-patch and git send-email. I'm happy using git am -s on patches posted here; it's actually less work for quick stuff than using git cherry-pick. Rebasing rather > than merging would make it easier to generate incremental patches, but > that is "bad" for people tracking your branch since they can't fast- > forward. Right, rebasing is mean. Of course, I don't quite understand why merging would generate anything different in the way of a patch, but perhaps there's something funny with how svn does merges? -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: cherry-pick to master
On Oct 13, 2009, at 13:16, Keith Packard wrote: Excerpts from Jeremy Huddleston's message of Tue Oct 13 12:59:19 -0700 2009: Hi Keith, Can you please pull these two commits into master: 6980f77892e0409b44bd8f33ba82e7273c6462a4 7e178ffbed7c8557faf8d471ad275aa2b0365e1d I'm still waiting on Peter's "best git practices" documentation before making my apple feature tree. In general, I think the idea was that patches be merged to master, tested there, and then pulled back to the version branches. Is there some reason you're doing this kind of development and testing on the 1.7 branch instead of from master? Are you finding master too unstable to be used for this kind of development? No, I actually tested these on master and am living on master... but since I can't commit to master by policy (merge to master from feature branches), and I don't have an apple feature branch tracking master (since I'm waiting for Peter's documentation on the best practices for that), the only place I could put them in git for you was on my 1.7 branch... but I assure you I'm actually using them on master myself. As we work on refining our source management policies, it would be useful to get feedback on how things are working for developers and maintainers. Ideally, I'd like to see you maintaining a branch or repository off of the master X server branch and be I'd merging rather than cherry-picking patches to master. Yeah, that's what I want as well, but I'm waiting for Peter's "best practices" wiki page to figure out the best way to do that since our 1.6 feature branch is not that clean. With my feature branch off of 1.6 (xorg-server-1.6-apple), we ran into a bit of a headache as server-1.6-branch diverged a bit... it is non- trivial to provide incremental patches from 1.6.5 to 1.6.5-apple1 at this point because we've been doing "svn merge origin/server-1.6- branch" into xorg-server-1.6-apple along the way. Rebasing rather than merging would make it easier to generate incremental patches, but that is "bad" for people tracking your branch since they can't fast- forward. --Jeremy smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: cherry-pick to master
Excerpts from Jeremy Huddleston's message of Tue Oct 13 12:59:19 -0700 2009: > Hi Keith, > > Can you please pull these two commits into master: > > 6980f77892e0409b44bd8f33ba82e7273c6462a4 > 7e178ffbed7c8557faf8d471ad275aa2b0365e1d > > I'm still waiting on Peter's "best git practices" documentation before > making my apple feature tree. In general, I think the idea was that patches be merged to master, tested there, and then pulled back to the version branches. Is there some reason you're doing this kind of development and testing on the 1.7 branch instead of from master? Are you finding master too unstable to be used for this kind of development? As we work on refining our source management policies, it would be useful to get feedback on how things are working for developers and maintainers. Ideally, I'd like to see you maintaining a branch or repository off of the master X server branch and be I'd merging rather than cherry-picking patches to master. -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
cherry-pick to master
Hi Keith, Can you please pull these two commits into master: 6980f77892e0409b44bd8f33ba82e7273c6462a4 7e178ffbed7c8557faf8d471ad275aa2b0365e1d I'm still waiting on Peter's "best git practices" documentation before making my apple feature tree. Thanks, Jeremy commit 7e178ffbed7c8557faf8d471ad275aa2b0365e1d Author: Jeremy Huddleston Date: Tue Oct 13 12:54:56 2009 -0700 Rootless: src drawable window can now be NULL Fix a possible crash when pSrc->pDrawable is NULL. Signed-off-by: Colin Harrison Signed-off-by: Jeremy Huddleston commit 6980f77892e0409b44bd8f33ba82e7273c6462a4 Author: Jeremy Huddleston Date: Tue Oct 13 12:54:11 2009 -0700 Rootless: Abstract some of the Xplugin specific stuff which has crept into rootlessWindow.c The rootless extension now directly calls some Xplugin functions, and relies on types defined in Xplugin.h, which isn't very abstracted :-) This patch is a start at abstracting some of the Xplugin specific stuff which has crept into rootlessWindow.c. This has been done in a pretty mindless fashion, without much thought as to if the additions to the generic rootless interface are the correct ones There is some confusion as to if RootlesscolormapCallback() returns a Bool or xp_error_enum value (not so abstact), but I have no way of checking, of finding out if Xplugin actually checks the result :-) Based on patches from Colin Harrison, Jon Turney and Yaakov Selkowitz Signed-off-by: Jon TURNEY Signed-off-by: Jeremy Huddleston smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Rootless: src drawable window can now be NULL
On Oct 13, 2009, at 01:45, Colin Harrison wrote: Hi, This is one for Jeremy Huddleston and Jon Turney. Found when testing rootless modes in Xming using the new xeyes (uses Xrender to anti-alias). Patch to fix the crash and make it work... Looks like we need this in RootlessGlyphs as well... Signed-off-by: Jeremy Huddleston diff --git a/miext/rootless/rootlessScreen.c b/miext/rootless/ rootlessScreen.c index b10ca70..c73d517 100644 --- a/miext/rootless/rootlessScreen.c +++ b/miext/rootless/rootlessScreen.c @@ -257,7 +257,7 @@ RootlessComposite(CARD8 op, PicturePtr pSrc, PicturePtr pMask, PicturePtr pDst, maskWin = (pMask->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pMask->pDrawable : NULL; } -srcWin = (pSrc->pDrawable->type == DRAWABLE_WINDOW) ? +srcWin = (pSrc->pDrawable && pSrc->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pSrc->pDrawable : NULL; dstWin = (pDst->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pDst->pDrawable : NULL; @@ -297,7 +297,7 @@ RootlessGlyphs(CARD8 op, PicturePtr pSrc, PicturePtr pDst, GlyphPtr glyph; WindowPtr srcWin, dstWin; -srcWin = (pSrc->pDrawable->type == DRAWABLE_WINDOW) ? +srcWin = (pSrc->pDrawable && pSrc->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pSrc->pDrawable : NULL; dstWin = (pDst->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pDst->pDrawable : NULL; smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Add support for RENDER BGRA formats.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Oct 13, 2009, at 2:51 PM, Adam Jackson wrote: > On Fri, 2009-10-09 at 11:26 +0200, Mark Kettenis wrote: > >>> Hmm, right. The two hunks above were aimed towards my first >>> approach for >>> fixing radeon KMS on big endian machines, by making the root window >>> visual BGRA. I've since abandoned that approach for a different >>> one, so >>> those hunks are not needed anymore and obviously even harmful. I'll >>> submit a patch to revert them. >> >> Well, it would be nice if a solution to support BGRA properly would >> be >> found. I have an i128-based card designed for Sun UltraSPARC >> workstations >> that can't do the byteswaps in hardware like the radeons can. > > Not that you're wrong (about proper BGRA support), but I think you may > be wrong (about i128). I'd like to see an X log from that chip with > Option "Debug" "on" in xorg.conf, I suspect CMD_HDF and MWn_CTRL > will be > interesting. ... which reminds me - I have an SBus card with ( among others ) an I128. I wrote an accelerated kernel driver for NetBSD using the X driver as reference, but the X driver doesn't support any mono-to- colour expansion. Does anyone have any I128 docs? Or does the chip simply not support colour expansion? I have never heard of any i128 PCI cards for Suns - do you have a model name or something? Most PCI graphics chips have their (framebuffer) apertures split into a big endian and a little endian half, some have programmable byte twiddling, some have both. It would be a strange choice to pick one of the few chips that don't support big endian mode for a big endian machine. So, it's probably there somewhere. Also, it might give you a hint or two if you ran the OF console in 24 bit ( output-device=screen:r1152x900x76x24 works on at least some Sun graphics boards ) and then check if the address property agrees with the framebuffer BAR ( there should be an entry for it in /memory/ translations, 'address' is an OF virtual address after all ) Or, just check what's halfway up the framebuffer aperture. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBStTTkMpnzkX8Yg2nAQIQKQgAkdzuuwxcFON4cPxYtMsePDIjzUXAkZhQ H55snPB5COunbiwvD2qgq9P4H+eFw3sS675wWKDVtlWht5aKRP+PpF5oZiSSVp8z b5LScg7CCGHGsD8LZXn6U8WmHAA/gdZGKU9EBpneJjQwzIzgFRqrVzYUt+3DyhMu nl6+8yeKtqq+shheai1zApglDtPwD9yiAMOQUObLsE+LiN4S1zlDZfy9pp5jsNcy FmQe99F/AaqiUdmV9O6iZ7nhgAY/rus4bR/UYmc7RnfJINZsNcYvHtCLJq9ynxGE kIHeWOUmB03D/rKykg1Y4q67oWizjXW/ouQRA+jTE7rOilPXKa9Bsw== =1Vw3 -END PGP SIGNATURE- ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Rootless: Abstract some of the Xplugin specific stuff which has crept into rootlessWindow.c
On Oct 9, 2009, at 11:13, Jon TURNEY wrote:
The rootless extension now directly calls some Xplugin functions,
and relies
on types defined in Xplugin.h, which isn't very abstracted :-)
This patch is a start at abstracting some of the Xplugin specific
stuff which
has crept into rootlessWindow.c. This has been done in a pretty
mindless fashion,
without much thought as to if the additions to the generic rootless
interface are
the correct ones
There is some confusion as to if RootlesscolormapCallback() returns
a Bool or
xp_error_enum value (not so abstact), but I have no way of checking,
of finding
out if Xplugin actually checks the result :-)
Based on patches from Colin Harrison, Jon Turney and Yaakov Selkowitz
Signed-off-by: Jon TURNEY
I've merged your two patches and edited it a bit to fix some
compilation warnings and errors. Please give it a review/test on your
end.
Signed-off-by: Jeremy Huddleston
diff --git a/hw/xquartz/xpr/xprFrame.c b/hw/xquartz/xpr/xprFrame.c
index a3e2076..53dde7a 100644
--- a/hw/xquartz/xpr/xprFrame.c
+++ b/hw/xquartz/xpr/xprFrame.c
@@ -83,6 +83,8 @@ static void xprDamageRects(RootlessFrameID wid, int
nrects, const BoxRec *rects,
int shift_x, int shift_y);
static void xprSwitchWindow(RootlessWindowPtr pFrame, WindowPtr
oldWin);
static Bool xprDoReorderWindow(RootlessWindowPtr pFrame);
+static void xprHideWindow(RootlessFrameID wid);
+static void xprUpdateColormap(RootlessFrameID wid, ScreenPtr pScreen);
static void xprCopyWindow(RootlessFrameID wid, int dstNrects, const
BoxRec *dstRects,
int dx, int dy);
@@ -117,6 +119,11 @@ xprSetNativeProperty(RootlessWindowPtr pFrame)
}
}
+static xp_error
+xprColormapCallback(void *data, int first_color, int n_colors,
uint32_t *colors)
+{
+return (RootlessResolveColormap (data, first_color, n_colors,
colors) ? XP_Success : XP_BadMatch);
+}
/*
* Create and display a new frame.
@@ -142,7 +149,7 @@ xprCreateFrame(RootlessWindowPtr pFrame, ScreenPtr
pScreen,
if (pWin->drawable.depth == 8)
{
wc.depth = XP_DEPTH_INDEX8;
-wc.colormap = RootlessColormapCallback;
+wc.colormap = xprColormapCallback;
wc.colormap_data = pScreen;
mask |= XP_COLORMAP;
}
@@ -447,6 +454,8 @@ static RootlessFrameProcsRec xprRootlessProcs = {
xprDamageRects,
xprSwitchWindow,
xprDoReorderWindow,
+xprHideWindow,
+xprUpdateColormap,
xp_copy_bytes,
xp_fill_bytes,
xp_composite_pixels,
@@ -593,3 +602,39 @@ xprHideWindows(Bool hide)
}
}
}
+
+// XXX: identical to x_cvt_vptr_to_uint ?
+#define MAKE_WINDOW_ID(x) ((xp_window_id)((size_t)(x)))
+
+Bool no_configure_window;
+
+static inline int
+configure_window (xp_window_id id, unsigned int mask,
+ const xp_window_changes *values)
+{
+ if (!no_configure_window)
+return xp_configure_window (id, mask, values);
+ else
+return XP_Success;
+}
+
+
+static
+void xprUpdateColormap(RootlessFrameID wid, ScreenPtr pScreen)
+{
+ /* This is how we tell xp that the colormap may have changed. */
+ xp_window_changes wc;
+ wc.colormap = xprColormapCallback;
+ wc.colormap_data = pScreen;
+
+ configure_window(MAKE_WINDOW_ID(wid), XP_COLORMAP, &wc);
+}
+
+static
+void xprHideWindow(RootlessFrameID wid)
+{
+ xp_window_changes wc;
+ wc.stack_mode = XP_UNMAPPED;
+ wc.sibling = 0;
+ configure_window(MAKE_WINDOW_ID(wid), XP_STACKING, &wc);
+}
diff --git a/hw/xwin/winscrinit.c b/hw/xwin/winscrinit.c
index eab0c6c..99d5a46 100644
--- a/hw/xwin/winscrinit.c
+++ b/hw/xwin/winscrinit.c
@@ -58,8 +58,10 @@ winMWExtWMProcs = {
winMWExtWMDamageRects,
#endif
winMWExtWMRootlessSwitchWindow,
- NULL,//winWMExtWMDoReorderWindow,
-
+ NULL,//winMWExtWMDoReorderWindow,
+ NULL,//winMWExtWMHideWindow,
+ NULL,//winMWExtWMUpdateColorMap,
+
NULL,//winMWExtWMCopyBytes,
NULL,//winMWExtWMFillBytes,
NULL,//winMWExtWMCompositePixels,
diff --git a/miext/rootless/rootless.h b/miext/rootless/rootless.h
index bde4cff..00eac4e 100644
--- a/miext/rootless/rootless.h
+++ b/miext/rootless/rootless.h
@@ -351,6 +351,13 @@ typedef void (*RootlessCopyWindowProc)
(RootlessFrameID wid, int dstNrects, const BoxRec *dstRects,
int dx, int dy);
+
+typedef void (*RootlessHideWindowProc)
+ (RootlessFrameID wid);
+
+typedef void (*RootlessUpdateColormapProc)
+ (RootlessFrameID wid, ScreenPtr pScreen);
+
/*
* Rootless implementation function list
*/
@@ -374,6 +381,8 @@ typedef struct _RootlessFrameProcs {
/* Optional frame functions */
RootlessSwitchWindowProc SwitchWindow;
RootlessDoReorderWindowProc DoReorderWindow;
+RootlessHideWindowProc HideWindow;
+RootlessUpdateColormapProc UpdateColormap;
/* Optional acceleration functions */
RootlessCopyBytesProc CopyBytes;
diff --git a/miext/rootless/rootlessCommon.c b/miext/rootless/
rootlessCommon.c
index e3dd9d9..39a3eed 100644
---
Re: [PATCH] Add support for RENDER BGRA formats.
On Fri, 2009-10-09 at 11:26 +0200, Mark Kettenis wrote: > > Hmm, right. The two hunks above were aimed towards my first approach for > > fixing radeon KMS on big endian machines, by making the root window > > visual BGRA. I've since abandoned that approach for a different one, so > > those hunks are not needed anymore and obviously even harmful. I'll > > submit a patch to revert them. > > Well, it would be nice if a solution to support BGRA properly would be > found. I have an i128-based card designed for Sun UltraSPARC workstations > that can't do the byteswaps in hardware like the radeons can. Not that you're wrong (about proper BGRA support), but I think you may be wrong (about i128). I'd like to see an X log from that chip with Option "Debug" "on" in xorg.conf, I suspect CMD_HDF and MWn_CTRL will be interesting. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
bitmaps stipple
the stipple bitmaps from the 'app/bitmap' and 'data/bitmaps' modules collide on case-insensitive file systems: http://cgit.freedesktop.org/xorg/data/bitmaps/tree/stipple http://cgit.freedesktop.org/xorg/app/bitmap/tree/Stipple What's the best way to solve this issue? Why are there two stipple bitmaps, and why are they different? smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Rootless: src drawable window can now be NULL
That looks like a sane enough sanity check... but why was pSrc- >pDrawable NULL in the first place? I'll check it out on XQuartz later today. On Oct 13, 2009, at 01:45, Colin Harrison wrote: Hi, This is one for Jeremy Huddleston and Jon Turney. Found when testing rootless modes in Xming using the new xeyes (uses Xrender to anti-alias). Patch to fix the crash and make it work... --- ./xserver/miext/rootless/rootlessScreen.c 2009-08-23 10:10:35.0 +0100 +++ ./test/miext/rootless/rootlessScreen.c 2009-10-13 09:34:49.0 +0100 @@ -257,8 +257,9 @@ RootlessComposite(CARD8 op, PicturePtr p maskWin = (pMask->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pMask->pDrawable : NULL; } -srcWin = (pSrc->pDrawable->type == DRAWABLE_WINDOW) ? - (WindowPtr)pSrc->pDrawable : NULL; +if (!pSrc->pDrawable) srcWin = NULL; +else srcWin = (pSrc->pDrawable->type == DRAWABLE_WINDOW) ? + (WindowPtr)pSrc->pDrawable : NULL; dstWin = (pDst->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pDst->pDrawable : NULL; Thanks, Colin Harrison ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glx: fixup deref of null pointer when glx screen init fails.
On Fri, Oct 02, 2009 at 04:28:54PM +0200, Luc Verhaegen wrote: > > In order to have this evaluated ASAP, i haven't set up an up to date > environment where i can build Xorg master yet, so this patch was not > even build tested. > >From 5f57d8c68e175d414a3b0b67eada61b645ae2f8c Mon Sep 17 00:00:00 2001 > From: Luc Verhaegen > Date: Fri, 2 Oct 2009 16:27:13 +0200 > Subject: [PATCH] GLX: further improve GLX protocol version handling. > > * The SERVER_GLX_*_VERSION defines now set the initial > GLXScreen->GLXMajor/Minor values directly. > * The GLXScreen->GLXMajor/Minor versions of the different providers now > are where glxMajor/MinorVersion get their values from. > * Keep the SERVER_GLX_*_VERSION defines where they belong to keep > natural segmentation intact. > > Warning: this patch was not even build tested. Builds and runs just fine. Luc Verhaegen. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Rootless: src drawable window can now be NULL
Hi, This is one for Jeremy Huddleston and Jon Turney. Found when testing rootless modes in Xming using the new xeyes (uses Xrender to anti-alias). Patch to fix the crash and make it work... --- ./xserver/miext/rootless/rootlessScreen.c 2009-08-23 10:10:35.0 +0100 +++ ./test/miext/rootless/rootlessScreen.c 2009-10-13 09:34:49.0 +0100 @@ -257,8 +257,9 @@ RootlessComposite(CARD8 op, PicturePtr p maskWin = (pMask->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pMask->pDrawable : NULL; } -srcWin = (pSrc->pDrawable->type == DRAWABLE_WINDOW) ? - (WindowPtr)pSrc->pDrawable : NULL; +if (!pSrc->pDrawable) srcWin = NULL; +else srcWin = (pSrc->pDrawable->type == DRAWABLE_WINDOW) ? + (WindowPtr)pSrc->pDrawable : NULL; dstWin = (pDst->pDrawable->type == DRAWABLE_WINDOW) ? (WindowPtr)pDst->pDrawable : NULL; Thanks, Colin Harrison ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v3] evdev: Support the "Calibration" string option.
On Tue, 2009-10-13 at 00:40 +0200, ext Peter Hutterer wrote:
> On Mon, Oct 12, 2009 at 04:32:51PM +0300, Oliver McFadden wrote:
> > Originally based on a patch from Daniel Stone, this commit allows for
> > the calibration factors to be set either from Xorg.conf or via HAL.
> >
> > Previously the only way was via the properties interface.
> > ---
> > man/evdev.man |5 +
> > src/evdev.c | 56
> >
> > 2 files changed, 41 insertions(+), 20 deletions(-)
> >
> > diff --git a/man/evdev.man b/man/evdev.man
> > index 4f15062..05626b5 100644
> > --- a/man/evdev.man
> > +++ b/man/evdev.man
> > @@ -150,6 +150,11 @@ be set in the configuration.
> > Number of reopen attempts after a read error occurs on the device (e.g.
> > after
> > waking up from suspend). In between each attempt is a 100ms wait. Default:
> > 10.
> > .TP 7
> > +.BI "Option \*qCalibration\*q \*q" "min-x max-x min-y max-y" \*q
> > +Calibrates the X and Y axes for devices that need to scale to a different
> > +coordinate system than reported to the X server.
> > +Property: "Evdev Axis Calibration".
> > +.TP 7
> > .BI "Option \*qSwapAxes\*q \*q" Bool \*q
> > Swap x/y axes. Default: off. Property: "Evdev Axes Swap".
> > .TP 7
> > diff --git a/src/evdev.c b/src/evdev.c
> > index 59cdd0d..d8d0f72 100644
> > --- a/src/evdev.c
> > +++ b/src/evdev.c
> > @@ -1949,12 +1949,32 @@ EvdevProbe(InputInfoPtr pInfo)
> > return 0;
> > }
> >
> > +static void
> > +EvdevSetCalibration(InputInfoPtr pInfo, int num_calibration, int
> > calibration[4])
> > +{
> > +EvdevPtr pEvdev = pInfo->private;
> > +
> > +if (num_calibration == 0) {
> > +pEvdev->flags &= ~EVDEV_CALIBRATED;
> > +pEvdev->calibration.min_x = 0;
> > +pEvdev->calibration.max_x = 0;
> > +pEvdev->calibration.min_y = 0;
> > +pEvdev->calibration.max_y = 0;
> > +} else if (num_calibration == 4) {
> > +pEvdev->flags |= EVDEV_CALIBRATED;
> > +pEvdev->calibration.min_x = calibration[0];
> > +pEvdev->calibration.max_x = calibration[1];
> > +pEvdev->calibration.min_y = calibration[2];
> > +pEvdev->calibration.max_y = calibration[3];
> > +}
> > +}
> >
> > static InputInfoPtr
> > EvdevPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
> > {
> > InputInfoPtr pInfo;
> > -const char *device;
> > +const char *device, *str;
> > +int num_calibration = 0, calibration[4] = { 0, 0, 0, 0 };
> > EvdevPtr pEvdev;
> >
> > if (!(pInfo = xf86AllocateInput(drv, 0)))
> > @@ -2027,6 +2047,20 @@ EvdevPreInit(InputDriverPtr drv, IDevPtr dev, int
> > flags)
> > pEvdev->invert_y = xf86SetBoolOption(pInfo->options, "InvertY", FALSE);
> > pEvdev->swap_axes = xf86SetBoolOption(pInfo->options, "SwapAxes",
> > FALSE);
> >
> > +str = xf86CheckStrOption(pInfo->options, "Calibration", NULL);
> > +if (str) {
> > +num_calibration = sscanf(str, "%d %d %d %d",
> > + &calibration[0], &calibration[1],
> > + &calibration[2], &calibration[3]);
> > +if (num_calibration == 4) {
> > +EvdevSetCalibration(pInfo, num_calibration, calibration);
> > +} else {
> > +xf86Msg(X_ERROR,
> > +"%s: Unsupported number of calibration factors: %d\n",
> > +pInfo->name, num_calibration);
> > +}
> > +}
> > +
> > /* Grabbing the event device stops in-kernel event forwarding. In other
> > words, it disables rfkill and the "Macintosh mouse button
> > emulation".
> > Note that this needs a server that sets the console to RAW mode. */
> > @@ -2502,25 +2536,7 @@ EvdevSetProperty(DeviceIntPtr dev, Atom atom,
> > XIPropertyValuePtr val,
> > return BadMatch;
> >
> > if (!checkonly)
> > -{
> > -if (val->size == 0)
> > -{
> > -pEvdev->flags &= ~EVDEV_CALIBRATED;
> > -pEvdev->calibration.min_x = 0;
> > -pEvdev->calibration.max_x = 0;
> > -pEvdev->calibration.min_y = 0;
> > -pEvdev->calibration.max_y = 0;
> > -} else if (val->size == 4)
> > -{
> > -CARD32 *vals = (CARD32*)val->data;
> > -
> > -pEvdev->flags |= EVDEV_CALIBRATED;
> > -pEvdev->calibration.min_x = vals[0];
> > -pEvdev->calibration.max_x = vals[1];
> > -pEvdev->calibration.min_y = vals[2];
> > -pEvdev->calibration.max_y = vals[3];
> > -}
> > -}
> > +EvdevSetCalibration(pInfo, val->size, val->data);
> > } else if (atom == prop_swap)
> > {
> > if (val->format != 8 || val->type != XA_INTEGER || val->size != 1)
> > --
> > 1.6.1
>
> ack, but I'd like to squash the following diff in before pushing, it's just
> more
[PATCH] xdpyinfo: Add support for --without-xf86misc
Since it's gone, I don't want it accidently finding a copy of xf86misc lying outside $prefix diff --git a/configure.ac b/configure.ac index 5d4e904..03c2fb4 100644 --- a/configure.ac +++ b/configure.ac @@ -78,13 +78,19 @@ else fi -PKG_CHECK_MODULES(DPY_XF86MISC, xxf86misc, - [SAVE_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $DPY_XF86MISC_CFLAGS $DPY_X11_CFLAGS" - AC_CHECK_HEADERS([X11/extensions/xf86misc.h X11/extensions/ xf86mscstr.h],,, - [#include +AC_ARG_WITH(xf86misc, AC_HELP_STRING([--without-xf86misc],[Disable xxf86misc support.]), + [USE_XF86MISC="$withval"], [USE_XF86MISC="yes"]) +if test "x$USE_XF86MISC" != "xno" ; then + PKG_CHECK_MODULES(DPY_XF86MISC, xxf86misc, + [SAVE_CPPFLAGS="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS $DPY_XF86MISC_CFLAGS $DPY_X11_CFLAGS" + AC_CHECK_HEADERS([X11/extensions/xf86misc.h X11/extensions/ xf86mscstr.h],,, + [#include #include ]) - CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) + CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) +else + echo "without xxf86misc" +fi PKG_CHECK_MODULES(DPY_XINPUT, xi, [SAVE_CPPFLAGS="$CPPFLAGS" smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xset: --without-{xf86misc,fontcache,xprint}
diff --git a/configure.ac b/configure.ac index 194514c..1b774ef 100644 --- a/configure.ac +++ b/configure.ac @@ -56,25 +56,43 @@ PKG_CHECK_MODULES(SET_XKB, x11, AC_CHECK_HEADERS([X11/XKBlib.h],,,[#include ]) CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) -PKG_CHECK_MODULES(SET_XF86MISC, xxf86misc, - [SAVE_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $SET_XF86MISC_CFLAGS $SET_X11_CFLAGS" - AC_CHECK_HEADERS([X11/extensions/xf86misc.h X11/extensions/ xf86mscstr.h],,, - [#include +AC_ARG_WITH(xf86misc, AC_HELP_STRING([--without-xf86misc],[Disable xf86misc support.]), +[USE_XF86MISC="$withval"], [USE_XF86MISC="yes"]) +if test "x$USE_XF86MISC" != "xno" ; then + PKG_CHECK_MODULES(SET_XF86MISC, xxf86misc, + [SAVE_CPPFLAGS="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS $SET_XF86MISC_CFLAGS $SET_X11_CFLAGS" + AC_CHECK_HEADERS([X11/extensions/xf86misc.h X11/extensions/ xf86mscstr.h],,, + [#include #include ]) - CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) + CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) +else +echo "without xf86misc" +fi -PKG_CHECK_MODULES(SET_FONTCACHE, xfontcache, - [SAVE_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $SET_FONTCACHE_CFLAGS $SET_X11_CFLAGS" - AC_CHECK_HEADERS([X11/extensions/fontcache.h X11/extensions/ fontcacheP.h],,,[#include ]) - CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) +AC_ARG_WITH(xfontcache, AC_HELP_STRING([--without-xfontcache], [Disable fontcache support.]), +[USE_XFONTCACHE="$withval"], [USE_XFONTCACHE="yes"]) +if test "x$USE_XFONTCACHE" != "xno" ; then + PKG_CHECK_MODULES(SET_FONTCACHE, xfontcache, + [SAVE_CPPFLAGS="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS $SET_FONTCACHE_CFLAGS $SET_X11_CFLAGS" + AC_CHECK_HEADERS([X11/extensions/fontcache.h X11/extensions/ fontcacheP.h],,,[#include ]) + CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) +else + echo "without xfontcache" +fi -PKG_CHECK_MODULES(SET_XPRINT, xp, - [SAVE_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $SET_XPRINT_CFLAGS $SET_X11_CFLAGS" - AC_CHECK_HEADERS([X11/extensions/Print.h],,,[#include ]) - CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) +AC_ARG_WITH(xprint, AC_HELP_STRING([--without-xprint],[Disable xprint support.]), +[USE_XPRINT="$withval"], [USE_XPRINT="yes"]) +if test "x$USE_XPRINT" != "xno" ; then + PKG_CHECK_MODULES(SET_XPRINT, xp, + [SAVE_CPPFLAGS="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS $SET_XPRINT_CFLAGS $SET_X11_CFLAGS" + AC_CHECK_HEADERS([X11/extensions/Print.h],,,[#include ]) + CPPFLAGS="$SAVE_CPPFLAGS"],[echo "not found"]) +else + echo "without xprint" +fi XSET_CFLAGS="$CWARNFLAGS $XSET_CFLAGS $SET_XEXT_CFLAGS $SET_XKB_CFLAGS $SET_XF86MISC_CFLAGS $SET_FONTCACHE_CFLAGS $SET_XPRINT_CFLAGS" XSET_LIBS="$XSET_LIBS $SET_XEXT_LIBS $SET_XKB_LIBS $SET_XF86MISC_LIBS $SET_FONTCACHE_LIBS $SET_XPRINT_LIBS" smime.p7s Description: S/MIME cryptographic signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
