[PATCH v2] parser: corrected xf86getBoolValue to use case insensitive compare
commit c6e8637e29e0ca11dfb35c02da7ca6002ac8c597 introduced this
regression; it can cause existing config files to be parsed incorrectly.
Acked-by: Julien Cristau jcris...@debian.org
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
Signed-off-by: Oliver McFadden oliver.mcfad...@nokia.com
---
hw/xfree86/parser/scan.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index b80fbfb..d25ada4 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/scan.c
@@ -1195,21 +1195,21 @@ xf86getBoolValue(Bool *val, const char *str)
if (*str == '\0') {
*val = TRUE;
} else {
- if (strcmp(str, 1) == 0)
+ if (xf86nameCompare(str, 1) == 0)
*val = TRUE;
- else if (strcmp(str, on) == 0)
+ else if (xf86nameCompare(str, on) == 0)
*val = TRUE;
- else if (strcmp(str, true) == 0)
+ else if (xf86nameCompare(str, true) == 0)
*val = TRUE;
- else if (strcmp(str, yes) == 0)
+ else if (xf86nameCompare(str, yes) == 0)
*val = TRUE;
- else if (strcmp(str, 0) == 0)
+ else if (xf86nameCompare(str, 0) == 0)
*val = FALSE;
- else if (strcmp(str, off) == 0)
+ else if (xf86nameCompare(str, off) == 0)
*val = FALSE;
- else if (strcmp(str, false) == 0)
+ else if (xf86nameCompare(str, false) == 0)
*val = FALSE;
- else if (strcmp(str, no) == 0)
+ else if (xf86nameCompare(str, no) == 0)
*val = FALSE;
else
return FALSE;
--
1.6.1
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
-fno-strict-aliasing in CWARNFLAGS?
Hi, When building Xming on Linux with a MinGW cross-compiler for Windows... I only get warnings about strict-aliasing from libX11 and libXt (i.e. when not using -fno-strict-aliasing). The xserver, pixman and Mesa are all happy bunnies strict. Now whether they work strict is another question! I'm trialling this at the moment (with only libX11 and libX11 built no-strict). Thanks, Colin Harrison ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Tue, 2010-02-02 at 16:18 -0500, Gaetan Nadon wrote:
On Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote:
What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS?
Do we actually have code somewhere that needs -fno-strict-aliasing? If so,
we should restrict -fno-strict-aliasing to that project (and try to address
the reason for the need) rather than putting it in util-macros.
I did a bit of research. This option has been used since the first day
in git for xserver:
+if test x$GCC = xyes; then
+ GCC_WARNINGS1=-Wall -Wpointer-arith -Wstrict-prototypes
+ GCC_WARNINGS2=-Wmissing-prototypes -Wmissing-declarations
+ GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing
+ GCC_WARNINGS=$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3
+ if test x$WERROR = xyes; then
+ GCC_WARNINGS=${GCC_WARNINGS} -Werror
+ fi
+ XSERVER_CFLAGS=$GCC_WARNINGS $XSERVER_CFLAGS
+fi
This is not a warning option, so it should not be there to begin with
(or the macro name was wrong). I tried to understand why it's there.
The gcc compiler makes optimization based on aliasing assumptions. If
the code does not follow the rules, it can cause runtime failure.
According to this post, the Perl code has removed the
-fno-strict-aliasing as it cannot safely assume that compilers
won't optimize anyway. They figured it was better to fix the
code, where applicable. That was in 2002.
http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html
There are posts about good code that failed under strict
aliasing optimization, only to be flagged afterwards by others
who demonstrated that the code worked by luck when not
optimized.
Help with understanding strict aliasing rules:
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
The rules about pointer type conversions are at 6.3.2.3. The
appropriate paragraphs are paragraphs 1 and 7:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
I have not seen any compelling reasons to turn off this optimization.
Maybe 10 years ago when it was first introduced. I have seen reports
of large number of warnings, but from older gcc versions. As it is
today, we are losing some optimization that could be beneficial.
I'd like to question that assertion. My impression has been that strict
aliasing is a concept only really understood by maybe a handful of
people, and I've seen kernel hackers much brighter than myself say it's
not worth the trouble.
Traditionally, -fno-strict-aliasing was definitely necessary for the X
server and/or some drivers to work correctly.
According to my gcc documentation, -Wstrict-aliasing=2 still seems
rather unsafe, and even -Wstrict-aliasing (which corresponds to
-Wstrict-aliasing=3) isn't perfect.
Due to all of the above, I think it would be prudent to at least
establish significant gains from strict aliasing before enabling it on a
wide scale.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Wed, 2010-02-03 at 10:15 +, Colin Harrison wrote: Michel Dänzer wrote: Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. Strict aliasing used to be a can'o worms... http://lkml.org/lkml/2003/2/26/158 and last time I tried strict aliasing for Xming (many moons ago) I fell flat on my face. But is series 4 gcc now much better? Problems with strict aliasing are usually due to strict aliasing violations in the code being compiled, not bugs in the compiler. So newer compilers can't really help (in fact the opposite may be true, as I think newer versions of gcc tend to obey strict aliasing even more strictly), the only help would be fixing the code bugs. I'm sure some of them have been fixed... We shall see (I'm testing with libX11 and libXt unchanged; but everything else ...most X.Org libs, most clients, pixman, Mesa and xserver... with strict aliasing) BTW I use -Os optimisation for all except -O2 for pixman and don't build any xserver drivers. According to the gcc 4.3 documentation: The `-fstrict-aliasing' option is enabled at levels `-O2', `-O3', `-Os'. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
RFC: EV_SW support in xf86-input-evdev
Hi, It seems that xf86-input-evdev doesn't support EV_SW events yet. I'd like to know if anyone has plans for adding the support in the near future. Also it'd be nice if you could offer some insight on why the support hasn't been implemented yet or how it will be implemented in the future. First I'll describe an example problem that would require switch support. I have a camera device that supports the following actions: focus, shoot and lens cover adjust. The focus and shoot actions are published as EV_KEY events (KEY_CAMERA_FOCUS, KEY_CAMERA) but the lens cover is a switch and therefore published as EV_SW (SW_CAMERA_LENS_COVER). All of these events originate from the Linux gpio-keys device. It'd be nice to be able to handle these events on a higher level without reading the kernel input device directly. I've though about different solutions for this but it seems reasonable to send the switch events as key events to clients. The main reason for this is that is should be possible to remap the switch events to generic keysyms for portability. A camera application would just handle key presses that it is interested in without having to use any specialized interfaces. The main problem is that the keycode and switch-code spaces could overlap, because the same input device is sending both key and switch events. This means that there has to be a way to either separate the code spaces or make a distinction between keys and switches. Some possible solutions that come to mind are listed below. 1. Blindly convert switch events to key events and don't worry about the overlap. Just assume that the input devices never send the same code as EV_KEY and EV_SW in practice. Also create a custom keyboard mapping for the device so that clients get whatever keysyms you want to use. 2. XKB starts to hopefully support high keycodes in the future. Add some magical constant such as 1024 to the switch-code to transform it into a keycode. Mapping to keysyms would be trivial and existing XKB interfaces could be used. If the same device would attempt to send key events with keycodes greater than 1024, those would be ignored as errors. This magic constant could be a device specific configuration option. 3. The key event contents could be amended with some subtype flag to tell whether the keycode of the events comes from a key or switch. Alternatively some modifier key could be configured as a switch key and would be turned on automatically for switch events. This is not a good solution because by default the clients won't check for the subtype and would just incorrectly handle switch events as key events. Also existing XKB interfaces would need to be extended to accept an extra subtype parameter so that mapping to keysyms would work correctly. 4. The most burdening approach would be to just introduce a new event for switch state changes. This seems like a huge overkill as the switch events aren't practically different from key events. If you were to implement switch support in the near future, what kind of approach would you take? Would it be sensible to just forget about this kind of support in the X server for the time being? Thanks for any insights, Rami ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Failure in detecting keyboard
Sergey Udaltsov wrote: Hi Peter Sergey, is there still reason for doing this? I note the commit dates back to 2004. Well, at that point in 2004 something did not work without it, so I created it. It was probably needed for trying to drop in xkb-config to to replace the xkb data in the XFree86 or Xorg monolithic builds (i.e. pre-7.0). The change to run xkbcomp from the bin directory instead of the data was made in Xorg in 2005: http://cgit.freedesktop.org/xorg/xserver/commit/?id=287336f3c9e5023acbfba6508b05a68ccca9ddf0 -- -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: Failure in detecting keyboard
Absolutely right! Thanks for reminding me that story! Anyway, it is now gone completely (in git) It was probably needed for trying to drop in xkb-config to to replace the xkb data in the XFree86 or Xorg monolithic builds (i.e. pre-7.0). The change to run xkbcomp from the bin directory instead of the data was made in Xorg in 2005: http://cgit.freedesktop.org/xorg/xserver/commit/?id=287336f3c9e5023acbfba6508b05a68ccca9ddf0 -- -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 util-macros 1/2] Don't disable strict aliasing (-fno-strict-aliasing) globally
On Tue, Feb 2, 2010 at 5:44 PM, Jeremy Huddleston jerem...@freedesktop.org wrote: Instead, we warn where this optimization might cause a problem! This was included for historic reasons and has persisted to the point of now infecting all X.org modules. Historically, it was just present in these modules before adding XORG_CWARNFLAGS to XORG_DEFAULT_OPTIONS: libICE libSM libX11 libXau libXfont libXft libXpm libXres xorg-server Most of these modules probably don't even need to disable this optimization, but if it is decided that this optimization should be disabled, it should be restricted to the required module rather than a global option. Signed-off-by: Jeremy Huddleston jerem...@apple.com --- xorg-macros.m4.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index caf61c2..40f5939 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -588,7 +588,7 @@ AC_DEFUN([XORG_CWARNFLAGS], [ AC_REQUIRE([AC_PROG_CC]) if test x$GCC = xyes ; then CWARNFLAGS=-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes \ --Wmissing-declarations -Wnested-externs -fno-strict-aliasing \ +-Wmissing-declarations -Wnested-externs -Wstrict-aliasing=2 \ -Wbad-function-cast case `$CC -dumpversion` in 3.4.* | 4.*) -- 1.6.2 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel Reviewed-by: Matt Turner matts...@gmail.com ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH util-macros 2/2] Add -Wformat=2 to the default CWARNFLAGS
On Tue, Feb 2, 2010 at 5:44 PM, Jeremy Huddleston jerem...@freedesktop.org wrote: This will include -Wformat-security to catch possible security problems in formatting in printf, scanf, etc. Signed-off-by: Jeremy Huddleston jerem...@apple.com --- xorg-macros.m4.in | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 40f5939..6d6f044 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -589,7 +589,7 @@ AC_REQUIRE([AC_PROG_CC]) if test x$GCC = xyes ; then CWARNFLAGS=-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes \ -Wmissing-declarations -Wnested-externs -Wstrict-aliasing=2 \ --Wbad-function-cast +-Wbad-function-cast -Wformat=2 case `$CC -dumpversion` in 3.4.* | 4.*) CWARNFLAGS=$CWARNFLAGS -Wold-style-definition -Wdeclaration-after-statement -- 1.6.2 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel Reviewed-by: Matt Turner matts...@gmail.com ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Tue, Feb 2, 2010 at 9:13 PM, Jeremy Huddleston
jerem...@freedesktop.org wrote:
On Feb 2, 2010, at 19:49, Dan Nicholson wrote:
- X11_REQUIRES=${X11_REQUIRES} xau xcmiscproto bigreqsproto
+ X11_REQUIRES=${X11_REQUIRES} xau [xcmiscproto = 1.2.0]
[bigreqsproto = 1.1.0]
Do these actually change anything? autoconf is just going to remove
the [] after processing through m4, and having = within quotes in
shell is fine. There's a lot of this excessive quoting/unquoting in
the x configure.ac's, and all that's really needed is to make sure
that the arguments to the autoconf m4 macros are quoted...
I did it more for stylistic reasons.
Fair enough. I doesn't hurt anything.
- PKG_CHECK_MODULES(BIGFONT, xf86bigfontproto,
+ PKG_CHECK_MODULES(BIGFONT, [xf86bigfontproto = 1.2.0],
like this. Can you show the warning that was being printed?
I'm not sure what you mean... I thought it was fairly obvious from the commit
message.
$ echo #include X11/extensions/xf86bigfstr.h | gcc -E - -o /dev/null
In file included from stdin:1:
./xf86bigfstr.h:1:2: warning: #warning xf86bigfstr.h is obsolete and may be
removed in the future.
./xf86bigfstr.h:2:2: warning: #warning include
X11/extensions/xf86bigfproto.h for the protocol defines.
Sorry, I thought you meant there were warnings from autoconf, too.
This obviously makes more sense.
Acked-by: Dan Nicholson dbn.li...@gmail.com
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
2010/2/3 Michel Dänzer mic...@daenzer.net:
On Tue, 2010-02-02 at 16:18 -0500, Gaetan Nadon wrote:
On Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote:
What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS?
Do we actually have code somewhere that needs -fno-strict-aliasing? If
so, we should restrict -fno-strict-aliasing to that project (and try to
address the reason for the need) rather than putting it in util-macros.
I did a bit of research. This option has been used since the first day
in git for xserver:
+if test x$GCC = xyes; then
+ GCC_WARNINGS1=-Wall -Wpointer-arith -Wstrict-prototypes
+ GCC_WARNINGS2=-Wmissing-prototypes -Wmissing-declarations
+ GCC_WARNINGS3=-Wnested-externs -fno-strict-aliasing
+ GCC_WARNINGS=$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3
+ if test x$WERROR = xyes; then
+ GCC_WARNINGS=${GCC_WARNINGS} -Werror
+ fi
+ XSERVER_CFLAGS=$GCC_WARNINGS $XSERVER_CFLAGS
+fi
This is not a warning option, so it should not be there to begin with
(or the macro name was wrong). I tried to understand why it's there.
The gcc compiler makes optimization based on aliasing assumptions. If
the code does not follow the rules, it can cause runtime failure.
According to this post, the Perl code has removed the
-fno-strict-aliasing as it cannot safely assume that compilers
won't optimize anyway. They figured it was better to fix the
code, where applicable. That was in 2002.
http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html
There are posts about good code that failed under strict
aliasing optimization, only to be flagged afterwards by others
who demonstrated that the code worked by luck when not
optimized.
Help with understanding strict aliasing rules:
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
The rules about pointer type conversions are at 6.3.2.3. The
appropriate paragraphs are paragraphs 1 and 7:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
I have not seen any compelling reasons to turn off this optimization.
Maybe 10 years ago when it was first introduced. I have seen reports
of large number of warnings, but from older gcc versions. As it is
today, we are losing some optimization that could be beneficial.
I'd like to question that assertion. My impression has been that strict
aliasing is a concept only really understood by maybe a handful of
people, and I've seen kernel hackers much brighter than myself say it's
not worth the trouble.
Here's one link:
http://lkml.org/lkml/2003/2/26/158
Traditionally, -fno-strict-aliasing was definitely necessary for the X
server and/or some drivers to work correctly.
I know in mesa it's been required. Here are two bugs fixed/worked
around by -fno-strict-aliasing.
https://bugs.freedesktop.org/show_bug.cgi?id=6046
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311
--
Dan
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
Would it make sense to keep compatibility with the old header locations instead of requiring the newer protos? I don't have a particular opinion either way, just thought I'd ask. Cheers, Julien ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
I think it makes sense because: 1) If people are updating their libX11, they can easily update their protos. 2) We're reporting that they're deprecated, so if we expect 3rd party clients of the headers to migrate, we should be willing to do it for our own code. 3) The server has already done it. 4) Fewer warnings make me happier, and I like being happy. On Feb 3, 2010, at 09:14, Julien Cristau wrote: Would it make sense to keep compatibility with the old header locations instead of requiring the newer protos? I don't have a particular opinion either way, just thought I'd ask. Cheers, Julien ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Wed, Feb 3, 2010 at 09:17:35 -0800, Jeremy Huddleston wrote: I think it makes sense because: 1) If people are updating their libX11, they can easily update their protos. I'm not completely sure about this one. Updating the protos requires updating the server to 1.7.x, which may not necessarily be as easy. It's probably possible to add some ifdefs to the new proto/lib headers to keep old xserver buildable, but it hasn't been done afaik. 2) We're reporting that they're deprecated, so if we expect 3rd party clients of the headers to migrate, we should be willing to do it for our own code. We can migrate while still staying compatible with the old stuff with a couple configure checks. 3) The server has already done it. 4) Fewer warnings make me happier, and I like being happy. ack. Cheers, Julien ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
2010/2/3 Michel Dänzer mic...@daenzer.net: On Wed, 2010-02-03 at 10:15 +, Colin Harrison wrote: Michel Dänzer wrote: Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. Strict aliasing used to be a can'o worms... http://lkml.org/lkml/2003/2/26/158 and last time I tried strict aliasing for Xming (many moons ago) I fell flat on my face. But is series 4 gcc now much better? Problems with strict aliasing are usually due to strict aliasing violations in the code being compiled, not bugs in the compiler. So newer compilers can't really help (in fact the opposite may be true, as I think newer versions of gcc tend to obey strict aliasing even more strictly), the only help would be fixing the code bugs. I'm sure some of them have been fixed... Here's an example of newer gcc changing behavior with strict aliasing that I just happened to see the other day. http://jeffreystedfast.blogspot.com/2010/01/weird-bugs-due-to-gcc-44-and-strict.html -- Dan ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input freeze
Hi Peter, On Tuesday 12 of January 2010 at 03:12:15, Peter Hutterer wrote: On Fri, Jan 08, 2010 at 09:08:52PM +0100, Oldřich Jedlička wrote: Dne Pá 8. ledna 2010 07:04:34 Peter Hutterer napsal(a): On Thu, Jan 07, 2010 at 10:13:24PM +0100, Oldřich Jedlička wrote: can I assume you only have one master device and you aren't playing around with MPX? what's the output of xinput --list --short? is the pad a floating slave? I can't reproduce it here, neither on 1.7 nor on master so I might need some special setup. I will add some logging to valuators update function (the code touched in your latest patch and updateStaveDeviceCoords) in the evening, just to be sure that the valuators are updated and kept correctly. If you point me to some other place in code, I can add logging there too. I've tried KDE4 just to be sure and it works correctly there. The KDE3.5 is affected by this bug. So I don't know if it makes sense to investigate it further (if it is bug in KDE3.5/Qt or xorg). weird. the only client thing that should trigger this behaviour is a direct XI2 slave grab. KDE 3.5 can't do that though, it came out way before XI2. I might have to dig out a kde installation to reproduce that. If you can ssh in during that time, please run xinput --list --short when this happens and see if the device got detached. Hi Peter, the `xinput --list --short` is exactly the same as without the problem - attached (is it the right command?). I'm able to ssh onto the machine, so if I should do something special with gdb, I can. Just point me into the right direction :-) thanks. xinput output doesn't show anything special so jury is still out on the problem. The interesting parts to look at with gdb are: Is GetPointerEvents being called for the device? If not, it's a driver issue. what's the value of dev-public.processInputEvent? If it's EnqueueEvent, the device is frozen by some client, you need to try to identify that client. Is dev-u.master still set or NULL? if the latter, it's temporarily detached from a grab and doesn't send core events. Those are the first three I'd look at to get a clue of what the issue might be. If the device isn't frozen, step through ProcessOtherEvents and see where and why the events disappear. I've finally got to the problem analysis. The Wacom input device isn't frozen, but the master device is. I've checked the input processing and in mieqProcessDeviceEvent the dev(Wacom Intuos3 6x8)-public.processInputProc is ProcessKeyboardEvent and the master(Virtual core pointer)-public.processInputProc is EnqueueEvent (which gets called at the end of mieqProcessDeviceEvent). Is this normal? Cheers, Oldřich. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
Ok.
In light of the discussion here, I think it would be best to take
Gaetan's option 3 here:
1) We should turn -fno-strict-aliasing on in the 9 (note that this
number does not include xf86 drivers) modules that traditionally had it:
libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server
xf86-* (somene else should check which ones traditionally had this
CFLAG)
2) We should remove it from the CWARNFLAGS in util-macros (and turn on
the warning)
3) We should audit the modules where we added it in #1 and slowly
remove it where safe.
--Jeremy
On Feb 3, 2010, at 10:55, Soeren Sandmann wrote:
Dan Nicholson dbn.li...@gmail.com writes:
Here's one link:
http://lkml.org/lkml/2003/2/26/158
Traditionally, -fno-strict-aliasing was definitely necessary for
the X
server and/or some drivers to work correctly.
I know in mesa it's been required. Here are two bugs fixed/worked
around by -fno-strict-aliasing.
https://bugs.freedesktop.org/show_bug.cgi?id=6046
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311
I recently turned it on in pixman because completely reasonable code
like this:
void
pixman_contract (uint32_t * dst,
const uint64_t *src,
int width)
{
int i;
/* Start at the beginning so that we can do the contraction in
* place when src == dst
*/
for (i = 0; i width; i++)
{
const uint8_t a = src[i] 56,
r = src[i] 40,
g = src[i] 24,
b = src[i] 8;
dst[i] = a 24 | r 16 | g 8 | b;
}
}
is actually illegal under the C aliasing rules, and GCC can and will
break it unless you use -fno-strict-aliasing. I don't think any other
compiler makes use of type based aliasing, perhaps because they
rightly - consider the standard broken.
Soren
___
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
[PATCH app-sessreg] Add AC_GNU_SOURCE which provides needed WTMPX_FILE define
The WTMPX_FILE is only defined under __USE_GNU conditional compilation. Autoconf provides AC_GNU_SOURCE which is a subset of AC_USE_SYSTEM_EXTENSIONS. It must be expanded before any other macros that uses the compiler. To reduce the risk of being misplaced, the statements have been grouped (mostly) as per the GNU standard layout.This macro requires Autoconf level 2.60 or later. The compilation failed under a GNU-Linux OS. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 32 +++- 1 files changed, 19 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index be1b4b4..6287a6b 100644 --- a/configure.ac +++ b/configure.ac @@ -20,25 +20,34 @@ dnl PERFORMANCE OF THIS SOFTWARE. dnl dnl Process this file with autoconf to create configure. -AC_PREREQ([2.57]) +# Initialize Autoconf +AC_PREREQ([2.60]) AC_INIT(sessreg, [1.0.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], sessreg) +AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([config.h]) +AC_CANONICAL_HOST +AC_GNU_SOURCE +AC_SYS_LARGEFILE + +# Initialize Automake AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -AM_CONFIG_HEADER(config.h) - -# Require xorg-macros 1.3 or later: XORG_DEFAULT_OPTIONS +# Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.3) + [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.4) +XORG_DEFAULT_OPTIONS +XORG_WITH_LINT +# Checks for programs. AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_INSTALL -XORG_DEFAULT_OPTIONS - +# Checks for header files. AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h]) AC_CHECK_MEMBER([struct utmpx.ut_syslen], HAVE_SYSLEN=1, @@ -46,15 +55,12 @@ AC_CHECK_MEMBER([struct utmpx.ut_syslen], [#include utmpx.h]) AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN, [utmpx structure includes ut_syslen field]) -AC_CHECK_FUNCS([updwtmpx utmpxname]) -AC_SYS_LARGEFILE +# Checks for typedefs, structures, and compiler characteristics. +AC_CHECK_FUNCS([updwtmpx utmpxname]) # Checks for pkg-config packages PKG_CHECK_MODULES(SESSREG, xproto) AC_SUBST(SESSREG_CFLAGS) -# Allow checking code with lint, sparse, etc. -XORG_WITH_LINT - AC_OUTPUT([Makefile]) -- 1.6.0.4 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Wed, Feb 3, 2010 at 11:24 AM, Jeremy Huddleston
jerem...@freedesktop.org wrote:
On Feb 3, 2010, at 09:31, Julien Cristau wrote:
On Wed, Feb 3, 2010 at 09:17:35 -0800, Jeremy Huddleston wrote:
2) We're reporting that they're deprecated, so if we expect 3rd party
clients of the headers to migrate, we should be willing to do it for
our own code.
We can migrate while still staying compatible with the old stuff with a
couple configure checks.
How about this then:
From 5c271b18b45b8e138b793e0a882fd894a488610b Mon Sep 17 00:00:00 2001
From: Jeremy Huddleston jerem...@apple.com
Date: Tue, 2 Feb 2010 15:48:42 -0800
Subject: [PATCH] Fix warnings for recent bigreqsproto, xcmiscproto, and
xf86bigfontproto
Signed-off-by: Jeremy Huddleston jerem...@apple.com
Acked-by: Dan Nicholson dbn.li...@gmail.com
---
configure.ac | 10 +++---
src/Font.c | 4
src/OpenDis.c | 4
src/XlibInt.c | 4
4 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0eea575..93d9959 100644
--- a/configure.ac
+++ b/configure.ac
@@ -60,13 +60,13 @@ AM_CONDITIONAL(XCB, test x$ac_cv_use_xcb != xno)
# Checks for pkg-config packages
# Always required
-X11_REQUIRES='xproto = 7.0.13 xextproto xtrans'
+X11_REQUIRES='[xproto = 7.0.13] xextproto xtrans'
PKG_PROG_PKG_CONFIG()
case $ac_cv_use_xcb in
no)
- X11_REQUIRES=${X11_REQUIRES} xau xcmiscproto bigreqsproto
+ X11_REQUIRES=${X11_REQUIRES} xau [xcmiscproto = 1.2.0]
[bigreqsproto = 1.1.0]
X11_EXTRA_DEPS=xau
PKG_CHECK_MODULES(XDMCP, xdmcp,
AC_CHECK_LIB(Xdmcp, XdmcpWrap,
@@ -186,6 +186,10 @@ AC_MSG_RESULT($XLIB_LOADABLE_XCURSOR)
AC_HEADER_STDC
AC_CHECK_HEADERS([sys/select.h])
+# Backwards compatability with older proto packages. This will be removed
eventually.
+# When removing, make sure to update Font.c OpenDis.c XlibInt.c
+AC_CHECK_HEADERS([X11/extensions/xcmiscproto.h
X11/extensions/bigreqsproto.h X11/extensions/xf86bigfproto.h], [], [],
[#include X11/Xproto.h])
Of course, since you've enforced newer xcmiscproto and friends in the
pkg-config checks, you'll always have these headers.
Another thing to think about is that libX11 is currently in 1.3 RC
phase, so it's reasonable to enforce newer proto versions in addition
to the version of xproto needed for generic events. We can branch from
before the generic events patches (75fe48e7a) and cherry pick patches
for a 1.2.x for people on more stable systems. In fact, there aleady
is libX11-1.2-branch.
--
Dan
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On 2010-02-03 15:02, Michael Cree wrote:
On 04/02/10 07:55, Soeren Sandmann wrote:
I recently turned it on in pixman because completely reasonable code
like this:
void
pixman_contract (uint32_t * dst,
const uint64_t *src,
int width)
{
int i;
/* Start at the beginning so that we can do the contraction in
* place when src == dst
*/
is actually illegal under the C aliasing rules, and GCC can and will
break it unless you use -fno-strict-aliasing.
I'm confused. Why does this break the aliasing rules?
If *dst and *src point to (alias) the same memory, it breaks the rules
since they are different types. The compiler is free to assume that dst
and src are disjoint. It may eg. unroll the loop and re-order the loads
and stores, resulting in something the programmer didn't expect if they
do overlap.
Peter Harris
--
Open Text Connectivity Solutions Group
Peter Harrishttp://connectivity.opentext.com/
Research and DevelopmentPhone: +1 905 762 6001
phar...@opentext.comToll Free: 1 877 359 4866
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app-sessreg] Add AC_GNU_SOURCE which provides needed WTMPX_FILE define
No adverse effects on darwin (non-GNU) Tested-by (on darwin): Jeremy Huddleston jerem...@apple.com On Feb 3, 2010, at 11:28, Gaetan Nadon wrote: The WTMPX_FILE is only defined under __USE_GNU conditional compilation. Autoconf provides AC_GNU_SOURCE which is a subset of AC_USE_SYSTEM_EXTENSIONS. It must be expanded before any other macros that uses the compiler. To reduce the risk of being misplaced, the statements have been grouped (mostly) as per the GNU standard layout.This macro requires Autoconf level 2.60 or later. The compilation failed under a GNU-Linux OS. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 32 +++- 1 files changed, 19 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index be1b4b4..6287a6b 100644 --- a/configure.ac +++ b/configure.ac @@ -20,25 +20,34 @@ dnl PERFORMANCE OF THIS SOFTWARE. dnl dnl Process this file with autoconf to create configure. -AC_PREREQ([2.57]) +# Initialize Autoconf +AC_PREREQ([2.60]) AC_INIT(sessreg, [1.0.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], sessreg) +AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([config.h]) +AC_CANONICAL_HOST +AC_GNU_SOURCE +AC_SYS_LARGEFILE + +# Initialize Automake AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -AM_CONFIG_HEADER(config.h) - -# Require xorg-macros 1.3 or later: XORG_DEFAULT_OPTIONS +# Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.3) + [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.4) +XORG_DEFAULT_OPTIONS +XORG_WITH_LINT +# Checks for programs. AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_INSTALL -XORG_DEFAULT_OPTIONS - +# Checks for header files. AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h]) AC_CHECK_MEMBER([struct utmpx.ut_syslen], HAVE_SYSLEN=1, @@ -46,15 +55,12 @@ AC_CHECK_MEMBER([struct utmpx.ut_syslen], [#include utmpx.h]) AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN, [utmpx structure includes ut_syslen field]) -AC_CHECK_FUNCS([updwtmpx utmpxname]) -AC_SYS_LARGEFILE +# Checks for typedefs, structures, and compiler characteristics. +AC_CHECK_FUNCS([updwtmpx utmpxname]) # Checks for pkg-config packages PKG_CHECK_MODULES(SESSREG, xproto) AC_SUBST(SESSREG_CFLAGS) -# Allow checking code with lint, sparse, etc. -XORG_WITH_LINT - AC_OUTPUT([Makefile]) -- 1.6.0.4 ___ 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 libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
Of course, since you've enforced newer xcmiscproto and friends in the pkg-config checks, you'll always have these headers. bah. yes. I'll back those out. Another thing to think about is that libX11 is currently in 1.3 RC phase, so it's reasonable to enforce newer proto versions in addition to the version of xproto needed for generic events. We can branch from before the generic events patches (75fe48e7a) and cherry pick patches for a 1.2.x for people on more stable systems. In fact, there aleady is libX11-1.2-branch. Yeah, I considered that as well, and I'd be fine either way. I'd prefer the original patch (forcing new protos), but I do believe the 1.2 branch is good enough for anyone stuck on old protos. 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 libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Wed, Feb 3, 2010 at 12:20 PM, Jeremy Huddleston jerem...@freedesktop.org wrote: Of course, since you've enforced newer xcmiscproto and friends in the pkg-config checks, you'll always have these headers. bah. yes. I'll back those out. Another thing to think about is that libX11 is currently in 1.3 RC phase, so it's reasonable to enforce newer proto versions in addition to the version of xproto needed for generic events. We can branch from before the generic events patches (75fe48e7a) and cherry pick patches for a 1.2.x for people on more stable systems. In fact, there aleady is libX11-1.2-branch. Yeah, I considered that as well, and I'd be fine either way. I'd prefer the original patch (forcing new protos), but I do believe the 1.2 branch is good enough for anyone stuck on old protos. I like the original patch for master, but maybe Julien has a different perspective. -- Dan ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Wed, Feb 3, 2010 at 12:21:13 -0800, Dan Nicholson wrote: I like the original patch for master, but maybe Julien has a different perspective. No that's fine. As far as I'm concerned you can go ahead with the original patch. Thanks! Cheers, Julien ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app-sessreg] Add AC_GNU_SOURCE which provides needed WTMPX_FILE define
Any reason to not just use AC_USE_SYSTEM_EXTENSIONS? I'm not aware of any problems we've hit in the other modules that are using that. -alan- Gaetan Nadon wrote: The WTMPX_FILE is only defined under __USE_GNU conditional compilation. Autoconf provides AC_GNU_SOURCE which is a subset of AC_USE_SYSTEM_EXTENSIONS. It must be expanded before any other macros that uses the compiler. To reduce the risk of being misplaced, the statements have been grouped (mostly) as per the GNU standard layout.This macro requires Autoconf level 2.60 or later. The compilation failed under a GNU-Linux OS. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 32 +++- 1 files changed, 19 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index be1b4b4..6287a6b 100644 --- a/configure.ac +++ b/configure.ac @@ -20,25 +20,34 @@ dnl PERFORMANCE OF THIS SOFTWARE. dnl dnl Process this file with autoconf to create configure. -AC_PREREQ([2.57]) +# Initialize Autoconf +AC_PREREQ([2.60]) AC_INIT(sessreg, [1.0.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], sessreg) +AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([config.h]) +AC_CANONICAL_HOST +AC_GNU_SOURCE +AC_SYS_LARGEFILE + +# Initialize Automake AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -AM_CONFIG_HEADER(config.h) - -# Require xorg-macros 1.3 or later: XORG_DEFAULT_OPTIONS +# Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.3) + [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.4) +XORG_DEFAULT_OPTIONS +XORG_WITH_LINT +# Checks for programs. AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_INSTALL -XORG_DEFAULT_OPTIONS - +# Checks for header files. AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h]) AC_CHECK_MEMBER([struct utmpx.ut_syslen], HAVE_SYSLEN=1, @@ -46,15 +55,12 @@ AC_CHECK_MEMBER([struct utmpx.ut_syslen], [#include utmpx.h]) AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN, [utmpx structure includes ut_syslen field]) -AC_CHECK_FUNCS([updwtmpx utmpxname]) -AC_SYS_LARGEFILE +# Checks for typedefs, structures, and compiler characteristics. +AC_CHECK_FUNCS([updwtmpx utmpxname]) # Checks for pkg-config packages PKG_CHECK_MODULES(SESSREG, xproto) AC_SUBST(SESSREG_CFLAGS) -# Allow checking code with lint, sparse, etc. -XORG_WITH_LINT - AC_OUTPUT([Makefile]) -- -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 libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
Dan Nicholson wrote: Another thing to think about is that libX11 is currently in 1.3 RC phase, so it's reasonable to enforce newer proto versions in addition to the version of xproto needed for generic events. We can branch from before the generic events patches (75fe48e7a) and cherry pick patches for a 1.2.x for people on more stable systems. In fact, there aleady is libX11-1.2-branch. 1.3 is already out stable. I don't think we've had a reason yet to split off a libX11-1.3-branch, since there's no changes proposed that would warrant a 1.4 bump. -- -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 libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Wed, Feb 3, 2010 at 12:28 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Dan Nicholson wrote: Another thing to think about is that libX11 is currently in 1.3 RC phase, so it's reasonable to enforce newer proto versions in addition to the version of xproto needed for generic events. We can branch from before the generic events patches (75fe48e7a) and cherry pick patches for a 1.2.x for people on more stable systems. In fact, there aleady is libX11-1.2-branch. 1.3 is already out stable. I don't think we've had a reason yet to split off a libX11-1.3-branch, since there's no changes proposed that would warrant a 1.4 bump. Oh, man, I was in an extremely stale checkout. Pushing newer proto versions doesn't seem like a nice thing to do in the middle of a stable branch. -- Dan ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11 1/2] Fix warnings for recent bigreqsproto, xcmiscproto, and xf86bigfontproto
On Feb 3, 2010, at 12:40, Dan Nicholson wrote: On Wed, Feb 3, 2010 at 12:28 PM, Alan Coopersmith alan.coopersm...@sun.com wrote: Dan Nicholson wrote: Another thing to think about is that libX11 is currently in 1.3 RC phase, so it's reasonable to enforce newer proto versions in addition to the version of xproto needed for generic events. We can branch from before the generic events patches (75fe48e7a) and cherry pick patches for a 1.2.x for people on more stable systems. In fact, there aleady is libX11-1.2-branch. 1.3 is already out stable. I don't think we've had a reason yet to split off a libX11-1.3-branch, since there's no changes proposed that would warrant a 1.4 bump. Oh, man, I was in an extremely stale checkout. Pushing newer proto versions doesn't seem like a nice thing to do in the middle of a stable branch. Ok, then how about we go with the 2nd patch (with the corrected/ unversioned requirements to the PKG_ macros) for the life of 1.3.x and plan on gutting that support whenever 1.4.x emerges? 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: -fno-strict-aliasing in CWARNFLAGS?
On 04/02/10 09:17, Peter Harris wrote:
On 2010-02-03 15:02, Michael Cree wrote:
On 04/02/10 07:55, Soeren Sandmann wrote:
I recently turned it on in pixman because completely reasonable code
like this:
void
pixman_contract (uint32_t * dst,
const uint64_t *src,
int width)
{
int i;
/* Start at the beginning so that we can do the contraction in
* place when src == dst
*/
is actually illegal under the C aliasing rules, and GCC can and will
break it unless you use -fno-strict-aliasing.
I'm confused. Why does this break the aliasing rules?
If *dst and *src point to (alias) the same memory, it breaks the rules
since they are different types.
Thanks, yes, it's now obvious.
Looking back at the code I now see that I completely missed the comment
that says it is possible that src == dest.
When I read code and see two different pointer types in the functions
arguments I naturally assume that it is _intended_ that they are two
different areas of memory. I always program like that and I guess that
programming practice comes from once knowing the C standard well many
years ago.
Cheers
Michael.
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] XACE and SELinux updates for master
On 01/24/2010 03:20 PM, Keith Packard wrote: On 01/06/2010 02:00 PM, Eamon Walsh wrote: xselinux: Allow SetWindowCreateContext to be used for pixmaps as well. This is a fairly significant change in extension semantics, and as such needs to be reflected throughout the stack, including an update to the extension minor version so that applications can tell whether this semantic is present in the X server. We've got several ways of doing this: 1) Create a new protocol request with the new semantics. Bonus credit for reporting an error if an old client uses the new request. 2) Detect the client version and change semantic for new clients. 3) Changing the semantic of the existing request. For the last two, we'll want to change the name of the request, library interface and server internal bits and then provide aliases for old libraries and clients. Hi Keith, I chose option (3) and renamed the requests. The SELinux extension doesn't have a traditional Xlib client side that needs to be changed, only XCB support. I have an XCB patch ready to alias the old names. Please pull these updates into master. Thanks. The following changes are available in the git repository at: git://anongit.freedesktop.org/~ewalsh/xserver master Eamon Walsh (8): xselinux: Allow SetWindowCreateContext to be used for pixmaps as well. libselinux now has a pkgconfig file. Use it. Revert Remove some debug messages that trigger on XACE event delivery failure. Don't print a failure message when XACE denies an input event delivery. xselinux: Remove reference counting calls for SID objects. xselinux: Allow GetWindowContext to be used for pixmaps as well. xselinux: Rename window-related requests that now support pixmaps. xselinux: Bump extension minor version. Xext/xselinux.h |8 ++-- Xext/xselinux_ext.c | 41 +++--- Xext/xselinux_hooks.c | 73 --- Xext/xselinux_label.c | 23 +- configure.ac| 11 ++- dix/events.c| 62 ++-- include/dix-config.h.in |2 - 7 files changed, 84 insertions(+), 136 deletions(-) ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] misc fixes and XKB cleanup
On Sun, Jan 24, 2010 at 13:07:29 -0800, Keith Packard wrote: On Tue, 19 Jan 2010 14:45:30 +1300, Peter Hutterer peter.hutte...@who-t.net wrote: dix: EventToCore needs to copy the root window too. This makes the xinput test fail -- it expects to see 0 for the root window. Is the test broken? Did this get resolved? What's the status of this pull request now? Thanks, Julien ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] misc fixes and XKB cleanup
On Wed, Feb 03, 2010 at 10:44:27PM +0100, Julien Cristau wrote: On Sun, Jan 24, 2010 at 13:07:29 -0800, Keith Packard wrote: On Tue, 19 Jan 2010 14:45:30 +1300, Peter Hutterer peter.hutte...@who-t.net wrote: dix: EventToCore needs to copy the root window too. This makes the xinput test fail -- it expects to see 0 for the root window. Is the test broken? Did this get resolved? What's the status of this pull request now? Correct fix committed as b4baab90c0d98bef98d485682d4a69a327a380d6. The fixes didn't get pulled in, Keith applied them himself instead. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH app-sessreg] Add AC_GNU_SOURCE which provides needed WTMPX_FILE define
On Wed, 2010-02-03 at 12:26 -0800, Alan Coopersmith wrote: Any reason to not just use AC_USE_SYSTEM_EXTENSIONS? I'm not aware of any problems we've hit in the other modules that are using that. -alan- No special reasons, other than being cautious about just using the minimum amount of medication :-) I was not sure if the new code (which requires GNU source) would be portable to other platforms (meaning non GNU compilers). Jeremy was kind enough to test it on darwin. I'll resubmit. For reference, in case of problems: — Macro: AC_USE_SYSTEM_EXTENSIONS This macro was introduced in Autoconf 2.60. If possible, enable extensions to C or Posix on hosts that normally disable the extensions, typically due to standards-conformance namespace issues. This should be called before any macros that run the C compiler. The following preprocessor macros are defined where appropriate: _GNU_SOURCE Enable extensions on GNU/Linux. __EXTENSIONS__ Enable general extensions on Solaris. _POSIX_PTHREAD_SEMANTICS Enable threading extensions on Solaris. _TANDEM_SOURCE Enable extensions for the HP NonStop platform. _ALL_SOURCE Enable extensions for AIX 3, and for Interix. _POSIX_SOURCE Enable Posix functions for Minix. _POSIX_1_SOURCE Enable additional Posix functions for Minix. _MINIX Identify Minix platform. This particular preprocessor macro is obsolescent, and may be removed in a future release of Autoconf. — Macro: _GNU_SOURCE If you define this macro, everything is included: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions. In the cases where POSIX.1 conflicts with BSD, the POSIX definitions take precedence. If you want to get the full effect of _GNU_SOURCE but make the BSD definitions take precedence over the POSIX definitions, use this sequence of definitions: #define _GNU_SOURCE #define _BSD_SOURCE #define _SVID_SOURCE Note that if you do this, you must link your program with the BSD compatibility library by passing the ‘-lbsd-compat’ option to the compiler or linker. NB: If you forget to do this, you may get very strange errors at run time. config.h seems to have dome the same amount of checking, using either macro. /* Enable extensions on AIX 3, Interix. */ #ifndef _ALL_SOURCE # define _ALL_SOURCE 1 #endif /* Enable GNU extensions on systems that have them. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif /* Enable threading extensions on Solaris. */ #ifndef _POSIX_PTHREAD_SEMANTICS # define _POSIX_PTHREAD_SEMANTICS 1 #endif /* Enable extensions on HP NonStop. */ #ifndef _TANDEM_SOURCE # define _TANDEM_SOURCE 1 #endif /* Enable general extensions on Solaris. */ #ifndef __EXTENSIONS__ # define __EXTENSIONS__ 1 #endif /* Number of bits in a file offset, on hosts where this is settable. */ /* #undef _FILE_OFFSET_BITS */ /* Define for large files, on AIX-style hosts. */ /* #undef _LARGE_FILES */ /* Define to 1 if on MINIX. */ /* #undef _MINIX */ /* Define to 2 if the system does not provide POSIX.1 features except with this defined. */ /* #undef _POSIX_1_SOURCE */ /* Define to 1 if you need to in order for `stat' and other things to work. */ /* #undef _POSIX_SOURCE */ Gaetan Nadon wrote: The WTMPX_FILE is only defined under __USE_GNU conditional compilation. Autoconf provides AC_GNU_SOURCE which is a subset of AC_USE_SYSTEM_EXTENSIONS. It must be expanded before any other macros that uses the compiler. To reduce the risk of being misplaced, the statements have been grouped (mostly) as per the GNU standard layout.This macro requires Autoconf level 2.60 or later. The compilation failed under a GNU-Linux OS. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 32 +++- 1 files changed, 19 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index be1b4b4..6287a6b 100644 --- a/configure.ac +++ b/configure.ac @@ -20,25 +20,34 @@ dnl PERFORMANCE OF THIS SOFTWARE. dnl dnl Process this file with autoconf to create configure. -AC_PREREQ([2.57]) +# Initialize Autoconf +AC_PREREQ([2.60]) AC_INIT(sessreg, [1.0.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], sessreg) +AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([config.h]) +AC_CANONICAL_HOST +AC_GNU_SOURCE +AC_SYS_LARGEFILE + +# Initialize Automake
[PATCH app-sessreg] Add AC_USE_SYSTEM_EXTENSIONS providing needed WTMPX_FILE define
The WTMPX_FILE is only defined under __USE_GNU conditional compilation. Autoconf provides AC_USE_SYSTEM_EXTENSIONS to enable platform extensions. It must be expanded before any other macros that uses the compiler. To reduce the risk of being misplaced, the statements have been grouped (mostly) as per the GNU standard layout.This macro requires Autoconf level 2.60 or later. The compilation failed under a GNU-Linux OS. Tested-by (on darwin): Jeremy Huddleston jerem...@apple.com Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac | 32 +++- 1 files changed, 19 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index be1b4b4..6287a6b 100644 --- a/configure.ac +++ b/configure.ac @@ -20,25 +20,34 @@ dnl PERFORMANCE OF THIS SOFTWARE. dnl dnl Process this file with autoconf to create configure. -AC_PREREQ([2.57]) +# Initialize Autoconf +AC_PREREQ([2.60]) AC_INIT(sessreg, [1.0.5], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], sessreg) +AC_CONFIG_SRCDIR([Makefile.am]) +AC_CONFIG_HEADERS([config.h]) +AC_CANONICAL_HOST +AC_GNU_SOURCE +AC_SYS_LARGEFILE + +# Initialize Automake AM_INIT_AUTOMAKE([foreign dist-bzip2]) AM_MAINTAINER_MODE -AM_CONFIG_HEADER(config.h) - -# Require xorg-macros 1.3 or later: XORG_DEFAULT_OPTIONS +# Require xorg-macros: XORG_DEFAULT_OPTIONS m4_ifndef([XORG_MACROS_VERSION], - [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.3) + [m4_fatal([must install xorg-macros 1.4 or later before running autoconf/autogen])]) +XORG_MACROS_VERSION(1.4) +XORG_DEFAULT_OPTIONS +XORG_WITH_LINT +# Checks for programs. AC_PROG_CC +AC_PROG_CC_C99 AC_PROG_INSTALL -XORG_DEFAULT_OPTIONS - +# Checks for header files. AC_CHECK_HEADERS([lastlog.h utmp.h utmpx.h sys/param.h]) AC_CHECK_MEMBER([struct utmpx.ut_syslen], HAVE_SYSLEN=1, @@ -46,15 +55,12 @@ AC_CHECK_MEMBER([struct utmpx.ut_syslen], [#include utmpx.h]) AC_DEFINE_UNQUOTED(HAVE_UTMPX_UT_SYSLEN,$HAVE_SYSLEN, [utmpx structure includes ut_syslen field]) -AC_CHECK_FUNCS([updwtmpx utmpxname]) -AC_SYS_LARGEFILE +# Checks for typedefs, structures, and compiler characteristics. +AC_CHECK_FUNCS([updwtmpx utmpxname]) # Checks for pkg-config packages PKG_CHECK_MODULES(SESSREG, xproto) AC_SUBST(SESSREG_CFLAGS) -# Allow checking code with lint, sparse, etc. -XORG_WITH_LINT - AC_OUTPUT([Makefile]) -- 1.6.0.4 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: Problem with mouse input freeze
On Wed, Feb 03, 2010 at 07:24:59PM +0100, Oldřich Jedlička wrote: the `xinput --list --short` is exactly the same as without the problem - attached (is it the right command?). I'm able to ssh onto the machine, so if I should do something special with gdb, I can. Just point me into the right direction :-) thanks. xinput output doesn't show anything special so jury is still out on the problem. The interesting parts to look at with gdb are: Is GetPointerEvents being called for the device? If not, it's a driver issue. what's the value of dev-public.processInputEvent? If it's EnqueueEvent, the device is frozen by some client, you need to try to identify that client. Is dev-u.master still set or NULL? if the latter, it's temporarily detached from a grab and doesn't send core events. Those are the first three I'd look at to get a clue of what the issue might be. If the device isn't frozen, step through ProcessOtherEvents and see where and why the events disappear. I've finally got to the problem analysis. The Wacom input device isn't frozen, but the master device is. I've checked the input processing and in mieqProcessDeviceEvent the dev(Wacom Intuos3 6x8)-public.processInputProc is ProcessKeyboardEvent and the master(Virtual core pointer)-public.processInputProc is EnqueueEvent (which gets called at the end of mieqProcessDeviceEvent). Is this normal? it the master pointer has a frozen grab, that's usually a sign of a client not releasing the grab. The VCP's processInputProc is changed to EnqueueEvent in response to grab with GrabModeSync on the pointer. the trick is finding the client that does it and then finding out what triggers the bug. The best way to narrow down the client is to ssh in and kill clients off one-by-one until the pointer is released. Once you've found which client it was, try to reproduce and verify. Once that's verified, you can go towards reproducing the steps that make the pointer freeze. given that your original scenario included a button configured as a key I guess that key would trigger some specific function, so it's likely that some client has a grab on that key. Kill off that client first and see if that helps. Next - use xmond or xscope to check if the event is delivered to that client properly. Could be that the server is doing something wrong. Best way to do that is have a server that works and compare the event flow from a test case. also try this patch from the list (or bugzilla), it's possible that this is the cause: dix: if owner-events is true for passive grabs, add the window mask (#25400) That's all I can recommend for now. Bugs like this are tricky to track down, the priority is always on getting a simple test case. Cheers, Peter ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On Wed, 2010-02-03 at 11:35 -0800, Jeremy Huddleston wrote:
Ok.
In light of the discussion here, I think it would be best to take
Gaetan's option 3 here:
1) We should turn -fno-strict-aliasing on in the 9 (note that this
number does not include xf86 drivers) modules that traditionally had it:
libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server
xf86-* (somene else should check which ones traditionally had this
CFLAG)
2) We should remove it from the CWARNFLAGS in util-macros (and turn on
the warning)
3) We should audit the modules where we added it in #1 and slowly
remove it where safe.
--Jeremy
I think this wikipedia article says it all:
http://en.wikipedia.org/wiki/Aliasing_(computing)
The Python project and Linux kernel are not observing strict alias
rules.
From a practical view point, the only *safe* way of changing the current
situation is to move the option from macros to each module. Some
exclusions are possible up-front like protos (just header files) and
fonts. Each module would then decide if they want to invest time and
effort to change/test their code. Some modules don't have maintainers,
so there will be no real change for them.
Gaetan
On Feb 3, 2010, at 10:55, Soeren Sandmann wrote:
Dan Nicholson dbn.li...@gmail.com writes:
Here's one link:
http://lkml.org/lkml/2003/2/26/158
Traditionally, -fno-strict-aliasing was definitely necessary for
the X
server and/or some drivers to work correctly.
I know in mesa it's been required. Here are two bugs fixed/worked
around by -fno-strict-aliasing.
https://bugs.freedesktop.org/show_bug.cgi?id=6046
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311
I recently turned it on in pixman because completely reasonable code
like this:
void
pixman_contract (uint32_t * dst,
const uint64_t *src,
int width)
{
int i;
/* Start at the beginning so that we can do the contraction in
* place when src == dst
*/
for (i = 0; i width; i++)
{
const uint8_t a = src[i] 56,
r = src[i] 40,
g = src[i] 24,
b = src[i] 8;
dst[i] = a 24 | r 16 | g 8 | b;
}
}
is actually illegal under the C aliasing rules, and GCC can and will
break it unless you use -fno-strict-aliasing. I don't think any other
compiler makes use of type based aliasing, perhaps because they
rightly - consider the standard broken.
Soren
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
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
Re: [PATCH:libXi] Initialize extension with the right number of events.
On Wed, Dec 9, 2009 at 14:06:36 +1000, Peter Hutterer wrote:
_X_HIDDEN
XExtDisplayInfo *XInput_find_display (Display *dpy)
{
@@ -180,10 +237,12 @@ XExtDisplayInfo *XInput_find_display (Display *dpy)
if (!xinput_info) { if (!(xinput_info = XextCreateExtension())) return
NULL; }
if (!(dpyinfo = XextFindDisplay (xinput_info, dpy)))
{
+ int nevents = _XiFindEventsSupported(dpy);
+
dpyinfo = XextAddDisplay (xinput_info, dpy,
xinput_extension_name,
xinput_extension_hooks,
-IEVENTS, NULL);
+nevents, NULL);
XESetWireToEventCookie(dpy, dpyinfo-codes-major_opcode,
XInputWireToCookie);
XESetCopyEventCookie(dpy, dpyinfo-codes-major_opcode,
XInputCopyCookie);
}
Apparently this makes qt3 apps crash when running on a server with no
XInputExtension.
qt_init_internal calls XListInputDevices (even without XI; bad qt!), and
XextAddDisplay returns here with dpyinfo-codes == NULL, so we crash on
the next line.
Reported as http://bugs.debian.org/568323 and reproduced with Xvfb
-extension XInputExtension (with an old Xvfb, since XI is mandatory
nowadays).
Cheers,
Julien
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] XACE and SELinux updates for master
On Wed, 03 Feb 2010 16:39:26 -0500, Eamon Walsh ewa...@tycho.nsa.gov wrote: I chose option (3) and renamed the requests. The SELinux extension doesn't have a traditional Xlib client side that needs to be changed, only XCB support. I have an XCB patch ready to alias the old names. Yeah, these seem good to me now. I know the kernel developers would like to see the patch sequence refactored so that the name changes occurred together, but I'm not sure I care that much as long as the final result looks good (and the intermediate versions build and run fine). Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgp3m5bnXrlyI.pgp Description: PGP signature ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
Michael Cree mc...@orcon.net.nz writes: What I do see is that the variables a, r, g and b are essentially declared unsigned char (what I presume uint8_t is typedefed to) and a calculation is performed that will lose its intended result due to shifting an unsigned char more bits to the left than is available in the unsigned char. The variables are promoted to int before the shift takes place, so the code works fine, apart from the aliasing issue. Soren ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH util-macros] doc: add XORG_ENABLE_DEVEL_DOCS and XORG_ENABLE_SPECS
Identical to XORG_ENABLE_DOCS, this macros allows modules to classify docs per type and selectively control their building. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 70 + 1 files changed, 70 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 8ad049b..b2bfc2f 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -676,6 +676,76 @@ AC_MSG_CHECKING([whether to build documentation]) AC_MSG_RESULT([$build_docs]) ]) # XORG_ENABLE_DOCS +# XORG_ENABLE_DEVEL_DOCS (enable_devel_docs=yes) +# +# Minimum version: 1.6.0 +# +# This macro enables a builder to skip all developer documentation. +# Combined with the specific tool checking macros XORG_WITH_*, it provides +# maximum flexibilty in controlling documentation building. +# Refer to: +# XORG_WITH_XMLTO --with-xmlto +# XORG_WITH_ASCIIDOC --with-asciidoc +# XORG_WITH_DOXYGEN --with-doxygen +# XORG_WITH_FOP --with-fop +# XORG_WITH_GROFF --with-groff +# XORG_WITH_PS2PDF--with-ps2pdf +# +# Interface to module: +# ENABLE_DEVEL_DOCS: used in makefiles to conditionally generate developer docs +# --enable-devel-docs: 'yes' user instructs the module to generate developer docs +# 'no' user instructs the module not to generate developer docs +# parm1: specify the default value, yes or no. +# +AC_DEFUN([XORG_ENABLE_DEVEL_DOCS],[ +devel_default=$1 +if test x$devel_default = x ; then + devel_default=yes +fi +AC_ARG_ENABLE(devel-docs, + AS_HELP_STRING([--enable-devel-docs], + [Enable building the developer documentation (default: yes)]), + [build_devel_docs=$enableval], [build_devel_docs=$devel_default]) +AM_CONDITIONAL(ENABLE_DEVEL_DOCS, [test x$build_devel_docs = xyes]) +AC_MSG_CHECKING([whether to build developer documentation]) +AC_MSG_RESULT([$build_devel_docs]) +]) # XORG_ENABLE_DEVEL_DOCS + +# XORG_ENABLE_SPECS (enable_specs=yes) +# +# Minimum version: 1.6.0 +# +# This macro enables a builder to skip all functional specification targets. +# Combined with the specific tool checking macros XORG_WITH_*, it provides +# maximum flexibilty in controlling documentation building. +# Refer to: +# XORG_WITH_XMLTO --with-xmlto +# XORG_WITH_ASCIIDOC --with-asciidoc +# XORG_WITH_DOXYGEN --with-doxygen +# XORG_WITH_FOP --with-fop +# XORG_WITH_GROFF --with-groff +# XORG_WITH_PS2PDF--with-ps2pdf +# +# Interface to module: +# ENABLE_SPECS:used in makefiles to conditionally generate specs +# --enable-specs: 'yes' user instructs the module to generate specs +# 'no' user instructs the module not to generate specs +# parm1: specify the default value, yes or no. +# +AC_DEFUN([XORG_ENABLE_SPECS],[ +spec_default=$1 +if test x$spec_default = x ; then + spec_default=yes +fi +AC_ARG_ENABLE(specs, + AS_HELP_STRING([--enable-specs], + [Enable building the specs (default: yes)]), + [build_specs=$enableval], [build_specs=$spec_default]) +AM_CONDITIONAL(ENABLE_SPECS, [test x$build_specs = xyes]) +AC_MSG_CHECKING([whether to build functional specifications]) +AC_MSG_RESULT([$build_specs]) +]) # XORG_ENABLE_SPECS + # XORG_CHECK_MALLOC_ZERO # -- # Minimum version: 1.0.0 -- 1.6.0.4 As discussed, these 2 additional macros will allow modules to qualify their documents as they see fit. Any preference? libXaw now used enable-docs but directory is called 'spec' How about xserver dmx and xfree86? http://wiki.x.org/wiki/Development/Documentation/WritingDocumentation ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: -fno-strict-aliasing in CWARNFLAGS?
On 04/02/10 14:28, Soeren Sandmann wrote: Michael Creemc...@orcon.net.nz writes: What I do see is that the variables a, r, g and b are essentially declared unsigned char (what I presume uint8_t is typedefed to) and a calculation is performed that will lose its intended result due to shifting an unsigned char more bits to the left than is available in the unsigned char. The variables are promoted to int before the shift takes place, so the code works fine, apart from the aliasing issue. Yeah, I remembered that once I thought about it a bit more after hitting the send button... oops :-/ I once knew all this stuff intimately; I could've even written out a complete operator precedence table from memory! Having only programmed in C on occasion over the last 12 years I now realise that some of that knowledge is getting a little hazy. While I unfortunately polluted the thread with my misguided ramblings I have nevertheless found this discussion very useful. Cheers Michael. ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xinput] man: document XI2 options
Document the options to modifiy the device hierarchy and change the ClientPointer. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- man/xinput.man | 29 + 1 files changed, 29 insertions(+), 0 deletions(-) diff --git a/man/xinput.man b/man/xinput.man index 7e1a9d3..42739fe 100644 --- a/man/xinput.man +++ b/man/xinput.man @@ -102,6 +102,35 @@ and ProximityOut are registered. Register for a number of XI2 events and display them. This option does not take a device argument. .PP +.TP 8 +.B --create-master \fIprefix\fP [sendCore] [enable] +Create a new pair of master devices on an XI2-enabled server with the given +prefix. The server will create one master pointer named prefix pointer +and one master keyboard named prefix keyboard. If sendCore is 1, this +pair of master devices is set to send core events (default). +If enable is 1, this master device pair will be enabled immediately. +.PP +.TP 8 +.B --remove-master \fIdevice\fP [Floating|AttachToMaster] [returnPointer] [returnKeyboard] +Remove the given master device and the paired master device. Attached slave +devices are set floating if Floating is specified or the argument is +omitted. If the second argument is AttachToMaster, returnPointer specifies +the master pointer to attach all slave pointers to and returnKeyboard specifies the +master keyboard to attach all slave keyboards to. +.PP +.TP 8 +.B --reattach \fIdevice\fP \fImaster\fP +Reattach the given device to the given master device. +.PP +.TP 8 +.B --float \fIdevice\fP +Float the given device (i.e. remove it from the master device). +.PP +.TP 8 +.B --set-cp \fIwindow\fP \fIdevice\fP +Set the ClientPointer for the client owning window to device. Device must +specify a master pointer. +.PP \fIdevice\fP can be the device name as a string or the XID of the device. .PP -- 1.6.6 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH util-macros] doc: add XORG_ENABLE_DEVEL_DOCS and XORG_ENABLE_SPECS
Reviewed-by: Jeremy Huddleston jerem...@apple.com On Feb 3, 2010, at 18:02, Gaetan Nadon wrote: Identical to XORG_ENABLE_DOCS, this macros allows modules to classify docs per type and selectively control their building. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 70 + 1 files changed, 70 insertions(+), 0 deletions(-) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 8ad049b..b2bfc2f 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -676,6 +676,76 @@ AC_MSG_CHECKING([whether to build documentation]) AC_MSG_RESULT([$build_docs]) ]) # XORG_ENABLE_DOCS +# XORG_ENABLE_DEVEL_DOCS (enable_devel_docs=yes) +# +# Minimum version: 1.6.0 +# +# This macro enables a builder to skip all developer documentation. +# Combined with the specific tool checking macros XORG_WITH_*, it provides +# maximum flexibilty in controlling documentation building. +# Refer to: +# XORG_WITH_XMLTO --with-xmlto +# XORG_WITH_ASCIIDOC --with-asciidoc +# XORG_WITH_DOXYGEN --with-doxygen +# XORG_WITH_FOP --with-fop +# XORG_WITH_GROFF --with-groff +# XORG_WITH_PS2PDF--with-ps2pdf +# +# Interface to module: +# ENABLE_DEVEL_DOCS: used in makefiles to conditionally generate developer docs +# --enable-devel-docs: 'yes' user instructs the module to generate developer docs +#'no' user instructs the module not to generate developer docs +# parm1: specify the default value, yes or no. +# +AC_DEFUN([XORG_ENABLE_DEVEL_DOCS],[ +devel_default=$1 +if test x$devel_default = x ; then + devel_default=yes +fi +AC_ARG_ENABLE(devel-docs, + AS_HELP_STRING([--enable-devel-docs], +[Enable building the developer documentation (default: yes)]), +[build_devel_docs=$enableval], [build_devel_docs=$devel_default]) +AM_CONDITIONAL(ENABLE_DEVEL_DOCS, [test x$build_devel_docs = xyes]) +AC_MSG_CHECKING([whether to build developer documentation]) +AC_MSG_RESULT([$build_devel_docs]) +]) # XORG_ENABLE_DEVEL_DOCS + +# XORG_ENABLE_SPECS (enable_specs=yes) +# +# Minimum version: 1.6.0 +# +# This macro enables a builder to skip all functional specification targets. +# Combined with the specific tool checking macros XORG_WITH_*, it provides +# maximum flexibilty in controlling documentation building. +# Refer to: +# XORG_WITH_XMLTO --with-xmlto +# XORG_WITH_ASCIIDOC --with-asciidoc +# XORG_WITH_DOXYGEN --with-doxygen +# XORG_WITH_FOP --with-fop +# XORG_WITH_GROFF --with-groff +# XORG_WITH_PS2PDF--with-ps2pdf +# +# Interface to module: +# ENABLE_SPECS: used in makefiles to conditionally generate specs +# --enable-specs:'yes' user instructs the module to generate specs +#'no' user instructs the module not to generate specs +# parm1: specify the default value, yes or no. +# +AC_DEFUN([XORG_ENABLE_SPECS],[ +spec_default=$1 +if test x$spec_default = x ; then + spec_default=yes +fi +AC_ARG_ENABLE(specs, + AS_HELP_STRING([--enable-specs], +[Enable building the specs (default: yes)]), +[build_specs=$enableval], [build_specs=$spec_default]) +AM_CONDITIONAL(ENABLE_SPECS, [test x$build_specs = xyes]) +AC_MSG_CHECKING([whether to build functional specifications]) +AC_MSG_RESULT([$build_specs]) +]) # XORG_ENABLE_SPECS + # XORG_CHECK_MALLOC_ZERO # -- # Minimum version: 1.0.0 -- 1.6.0.4 As discussed, these 2 additional macros will allow modules to qualify their documents as they see fit. Any preference? libXaw now used enable-docs but directory is called 'spec' How about xserver dmx and xfree86? http://wiki.x.org/wiki/Development/Documentation/WritingDocumentation ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
