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
---
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!
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
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
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.
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
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
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
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
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
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
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
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.
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
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...
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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; }
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,
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
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
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
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
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
---
43 matches
Mail list logo
