Re: events in evdev.c
Chuck Robey wrote: I'm really rather curious where you got the idea that FreeBSD had something that looked even vaguely like the Linux events. I know that if you look at the FreeBSD man page EVENTHANDLER(9) you can see an event interface, but that one is intra-kernel, not exported to applications like the Linux one is. Using the event interface, like evdev does, takes away the portability. If I could find a FreeBSD applications-event interface ala Linux, I would be overjoyed, and immediately use it. NetBSD and OpenBSD share (at least try to) the wscons console driver which has a notion of event which is not too far away from evdev. It should be possible to write a more OS neutral event based input driver which could cover all of Solaris, Linux and wscons events. I must admit that I don't know too much about the current state of the FreeBSD console driver though. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building Xephyr
Yan Seiner wrote: I am new to building X. I'd like to take a shot at building Xephyr from git. I've been through the instructions on http://www.x.org/wiki/Development/git but xserver doesn't appear to have xephyr. Is there a list somewhere of what module contains which part? Where do I find xephyr? Xephyr is part of kdrive, itself part of xserver. Build it with configure --disable-xorg --disable-xinput --enable-kdrive --disable-dmx --disable-xnest --disable-xvfb -- Matthieu Herrb smime.p7s Description: S/MIME Cryptographic Signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?
Jason Spiro wrote: Problem: Many[1] users have killed X by accident.[2] Solution idea: Make it harder to kill X by accident. E.g. you could change the key sequence users must press. * Maybe require Control+Alt+Backspace then Control-Alt-Y.[3] * Or require Control+K+X pressed simultaneously. What do you think? Should Xorg change this key sequence? Please vote yes or no. You can add comments too. If you reply only to me by private mail, I will eventually summarize your reply to the list. No Please stop changing X default behaviour to match indiviual developpers tastes. There are enough options to confgure it to your taste. X is a standard and most users expect the standard behaviour. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building X
Adam Jackson wrote: On Fri, 2008-09-19 at 16:55 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 13:52 -0400, Adam Jackson wrote: You don't ask for the stipple though. It's the default. My point was that if you want to avoid the vintage X appearance, you'd likely start the X server with a black root window instead of the ugly stipple, and we could hook the 'disable the cursor' mode to the same option. Does that seem like a reasonable combination? I just can't imagine any credible desktop environment wanting either the stipple or the X cursor. The protocol, by the way, does _not_ mandate the stipple. It says that the initial contents are some unspecified two-color pattern made of blackPixel and whitePixel. There is a weasel argument here that having zero white pixels still counts as two color I guess. Even if you don't like that argument, we are the keepers of the spec, there's no reason we can't relax that requirement. Yes, I'm cool with the black root background; nicer looking, conforming to the spec and everything. Right then. -br is now the default. -retro gives you the old school root window and cursor behavior. I see a bike shed and I want to paint it black... I have nothing against -br disabling the cursor, but keep it an option. to quote myself: Please stop changing X default behaviour to match indiviual developpers tastes. There are enough options to confgure it to your taste. X is a standard and most users expect the standard behaviour. Running the 'X' alone should produce the stippled background with the good old X cursor. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] close sockets in AbortServer()
Hi,
while implementing or testing new features, I'm getting tired of having
to remove the /tmp/.X11-unix/X0 socket that's left around when X
crashes. The attached patch fixes it.
I wonder if there are reasons for not doing that, or if it's some
oversight (may be the xtrans implementation for other kind of local
transports doen't need cleanup ?)
If there are no objections I'll commit it.
--
Matthieu Herrb
diff --git a/os/log.c b/os/log.c
index ca93eb8..d443aba 100644
--- a/os/log.c
+++ b/os/log.c
@@ -416,6 +416,7 @@ void AbortServer(void) __attribute__((noreturn));
void
AbortServer(void)
{
+CloseWellKnownConnections();
OsCleanup(TRUE);
CloseDownDevices();
AbortDDX();
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xquartz dereferencing a NULL pointer (patch 2)
Simon Thum wrote: Tiago Vignatti wrote: http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Does we have this kind of thing in C libraries? It would be useful. If I got it right, that's posix + pthreads functionality specialized for an amtel platform. So in general, yes. Sorry, but no. These macros are not standard at all, and without explicit using of some kind of lock, there no portable way to handle atomicity in pthreads afaik. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver 1.5.3: DeliverPropertyEvent() accessing unallocated memory
Matthieu Herrb wrote:
Hi,
using OpenBSD's memory allocator (which has an option to fill free()'d
memory with a specific pattern) I found out that xserver 1.5.3 is
dumping core on exit.
This is caused by a bad pointer caused by accessing free'd memory in
DeliverPropertyEvent, because when the RRProperties are destroyed, the
associated windows have been free'd already.
Here's a short debugging session that shows the problem (0xfd is the
value used to fill free()'d regions:
Program received signal SIGSEGV, Segmentation fault.
0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
34 pHead = LookupIDByType(pWin-drawable.id, RREventType);
(gdb) p **WindowTable
$1 = {drawable = {type = 223 'ß', class = 223 'ß', depth = 223 'ß',
bitsPerPixel = 223 'ß', id = 3755991007, x = -8225, y = -8225,
width = 57311, height = 57311, pScreen = 0xdfdfdfdf,
serialNumber = 3755991007}, devPrivates = 0xdfdfdfdf, parent =
0xdfdfdfdf,
nextSib = 0xdfdfdfdf, prevSib = 0xdfdfdfdf, firstChild = 0xdfdfdfdf,
lastChild = 0xdfdfdfdf, clipList = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderClip = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
valdata = 0xdfdfdfdf, winSize = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderSize = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
origin = {x = -8225, y = -8225}, borderWidth = 57311,
deliverableEvents = 57311, eventMask = 3755991007, background = {
pixmap = 0xdfdfdfdf, pixel = 3755991007}, border = {pixmap =
0xdfdfdfdf,
pixel = 3755991007}, backStorage = 0xdfdfdfdf, optional = 0xdfdfdfdf,
backgroundState = 3, borderIsPixel = 1, cursorIsNone = 1, backingStore
= 1,
saveUnder = 1, DIXsaveUnder = 1, bitGravity = 15, winGravity = 13,
overrideRedirect = 1, visibility = 3, mapped = 1, realized = 1,
viewable = 0, dontPropagate = 7, forcedBS = 1, redirectDraw = 3,
forcedBG = 1}
(gdb) bt
#0 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
#1 0x1c025c5c in TraverseTree (pWin=0x879d7900,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:225
#2 0x1c025d03 in WalkTree (pScreen=0x81310400,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:253
#3 0x1c148858 in RRDeliverPropertyEvent (pScreen=0x81310400,
event=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:62
#4 0x1c1488d2 in RRDeleteAllOutputProperties (output=0x88fa2000)
at /usr/xenocara/xserver/randr/rrproperty.c:80
#5 0x1c147c9f in RROutputDestroyResource (value=0x88fa2000, pid=60)
at /usr/xenocara/xserver/randr/rroutput.c:410
#6 0x1c025078 in FreeClientResources (client=0x7d3f1400)
at /usr/xenocara/xserver/dix/resource.c:809
#7 0x1c02515e in FreeAllResources ()
at /usr/xenocara/xserver/dix/resource.c:826
#8 0x1c021acd in main (argc=1, argv=0xcfbc2578, envp=0xcfbc2580)
at /usr/xenocara/xserver/dix/main.c:453
(gdb)
Ideas for fixing that are of course welcome.
I've added an ErrorF() call to FreeClientResources() to show the same
info as the DTrace probe in this function. It confirms that the
rootwindow (in the case of a simle server with no client windows) is
destroyed before the outputs:
FreeClientResources MODE 41 7c0c1f00
FreeClientResources MODE 40 7c0c1e00
FreeClientResources MODE 43 7c0c1a40
FreeClientResources MODE 42 7c0c1b40
FreeClientResources MODE 45 7c0c1d80
FreeClientResources MODE 44 7c0c1b00
FreeClientResources MODE 47 840e9100
FreeClientResources MODE 46 7c0c1ec0
FreeClientResources MODE 49 840e9300
FreeClientResources MODE 48 840e92c0
FreeClientResources MODE 4b 840e94c0
FreeClientResources MODE 4a 840e9140
FreeClientResources MODE 4d 840e9040
FreeClientResources MODE 4c 840e9380
FreeClientResources unknown 4f 840e90c0
FreeClientResources MODE 4e 7c0c1c40
FreeClientResources unknown 51 80e5ad20
FreeClientResources unknown 50 80e5a9e0
FreeClientResources COLORMAP 20 82d64000
FreeClientResources PICTFORMAT 23 7e959000
FreeClientResources PICTFORMAT 24 7e959030
FreeClientResources PICTFORMAT 25 7e959060
FreeClientResources PICTFORMAT 26 7e959090
FreeClientResources PICTFORMAT 27 7e9590c0
FreeClientResources PICTFORMAT 28 7e9590f0
FreeClientResources PICTFORMAT 29 7e959120
FreeClientResources PICTFORMAT 2a 7e959150
FreeClientResources PICTFORMAT 2b 7e959180
FreeClientResources PICTFORMAT 2c 7e9591b0
FreeClientResources PICTFORMAT 2d 7e9591e0
FreeClientResources PICTFORMAT 2e 7e959210
FreeClientResources PICTFORMAT 2f 7e959240
FreeClientResources PICTFORMAT 30 7e959270
FreeClientResources PICTFORMAT 31 7e9592a0
FreeClientResources PICTFORMAT 32 7e9592d0
FreeClientResources
xserver 1.5.3: DeliverPropertyEvent() accessing unallocated memory
Hi,
using OpenBSD's memory allocator (which has an option to fill free()'d
memory with a specific pattern) I found out that xserver 1.5.3 is
dumping core on exit.
This is caused by a bad pointer caused by accessing free'd memory in
DeliverPropertyEvent, because when the RRProperties are destroyed, the
associated windows have been free'd already.
Here's a short debugging session that shows the problem (0xfd is the
value used to fill free()'d regions:
Program received signal SIGSEGV, Segmentation fault.
0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
34 pHead = LookupIDByType(pWin-drawable.id, RREventType);
(gdb) p **WindowTable
$1 = {drawable = {type = 223 'ß', class = 223 'ß', depth = 223 'ß',
bitsPerPixel = 223 'ß', id = 3755991007, x = -8225, y = -8225,
width = 57311, height = 57311, pScreen = 0xdfdfdfdf,
serialNumber = 3755991007}, devPrivates = 0xdfdfdfdf, parent =
0xdfdfdfdf,
nextSib = 0xdfdfdfdf, prevSib = 0xdfdfdfdf, firstChild = 0xdfdfdfdf,
lastChild = 0xdfdfdfdf, clipList = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderClip = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
valdata = 0xdfdfdfdf, winSize = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderSize = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
origin = {x = -8225, y = -8225}, borderWidth = 57311,
deliverableEvents = 57311, eventMask = 3755991007, background = {
pixmap = 0xdfdfdfdf, pixel = 3755991007}, border = {pixmap =
0xdfdfdfdf,
pixel = 3755991007}, backStorage = 0xdfdfdfdf, optional = 0xdfdfdfdf,
backgroundState = 3, borderIsPixel = 1, cursorIsNone = 1, backingStore
= 1,
saveUnder = 1, DIXsaveUnder = 1, bitGravity = 15, winGravity = 13,
overrideRedirect = 1, visibility = 3, mapped = 1, realized = 1,
viewable = 0, dontPropagate = 7, forcedBS = 1, redirectDraw = 3,
forcedBG = 1}
(gdb) bt
#0 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
#1 0x1c025c5c in TraverseTree (pWin=0x879d7900,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:225
#2 0x1c025d03 in WalkTree (pScreen=0x81310400,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:253
#3 0x1c148858 in RRDeliverPropertyEvent (pScreen=0x81310400,
event=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:62
#4 0x1c1488d2 in RRDeleteAllOutputProperties (output=0x88fa2000)
at /usr/xenocara/xserver/randr/rrproperty.c:80
#5 0x1c147c9f in RROutputDestroyResource (value=0x88fa2000, pid=60)
at /usr/xenocara/xserver/randr/rroutput.c:410
#6 0x1c025078 in FreeClientResources (client=0x7d3f1400)
at /usr/xenocara/xserver/dix/resource.c:809
#7 0x1c02515e in FreeAllResources ()
at /usr/xenocara/xserver/dix/resource.c:826
#8 0x1c021acd in main (argc=1, argv=0xcfbc2578, envp=0xcfbc2580)
at /usr/xenocara/xserver/dix/main.c:453
(gdb)
Ideas for fixing that are of course welcome.
--
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DeliverPropertyEvent() accessing unallocated memory
Matthieu Herrb wrote:
Hi,
using OpenBSD's memory allocator (which has an option to fill free()'d
memory with a specific pattern) I found out that xserver 1.5.3 is
dumping core on exit.
Same problem on git's master.
This is caused by a bad pointer caused by accessing free'd memory in
DeliverPropertyEvent, because when the RRProperties are destroyed, the
associated windows have been free'd already.
So, no help on how to fix that? Should we just remove
RRDeleteAllOutputProperties() since it can't work?
Here's a short debugging session that shows the problem (0xfd is the
value used to fill free()'d regions:
Program received signal SIGSEGV, Segmentation fault.
0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
34 pHead = LookupIDByType(pWin-drawable.id, RREventType);
(gdb) p **WindowTable
$1 = {drawable = {type = 223 'ß', class = 223 'ß', depth = 223 'ß',
bitsPerPixel = 223 'ß', id = 3755991007, x = -8225, y = -8225,
width = 57311, height = 57311, pScreen = 0xdfdfdfdf,
serialNumber = 3755991007}, devPrivates = 0xdfdfdfdf, parent =
0xdfdfdfdf,
nextSib = 0xdfdfdfdf, prevSib = 0xdfdfdfdf, firstChild = 0xdfdfdfdf,
lastChild = 0xdfdfdfdf, clipList = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderClip = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
valdata = 0xdfdfdfdf, winSize = {extents = {x1 = -8225, y1 = -8225,
x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf}, borderSize = {extents = {
x1 = -8225, y1 = -8225, x2 = -8225, y2 = -8225}, data = 0xdfdfdfdf},
origin = {x = -8225, y = -8225}, borderWidth = 57311,
deliverableEvents = 57311, eventMask = 3755991007, background = {
pixmap = 0xdfdfdfdf, pixel = 3755991007}, border = {pixmap =
0xdfdfdfdf,
pixel = 3755991007}, backStorage = 0xdfdfdfdf, optional = 0xdfdfdfdf,
backgroundState = 3, borderIsPixel = 1, cursorIsNone = 1, backingStore
= 1,
saveUnder = 1, DIXsaveUnder = 1, bitGravity = 15, winGravity = 13,
overrideRedirect = 1, visibility = 3, mapped = 1, realized = 1,
viewable = 0, dontPropagate = 7, forcedBS = 1, redirectDraw = 3,
forcedBG = 1}
(gdb) bt
#0 0x1c1486f7 in DeliverPropertyEvent (pWin=0xdfdfdfdf, value=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:34
#1 0x1c025c5c in TraverseTree (pWin=0x879d7900,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:225
#2 0x1c025d03 in WalkTree (pScreen=0x81310400,
func=0x1c1486d0 DeliverPropertyEvent, data=0xcfbc2400)
at /usr/xenocara/xserver/dix/window.c:253
#3 0x1c148858 in RRDeliverPropertyEvent (pScreen=0x81310400,
event=0xcfbc2400)
at /usr/xenocara/xserver/randr/rrproperty.c:62
#4 0x1c1488d2 in RRDeleteAllOutputProperties (output=0x88fa2000)
at /usr/xenocara/xserver/randr/rrproperty.c:80
#5 0x1c147c9f in RROutputDestroyResource (value=0x88fa2000, pid=60)
at /usr/xenocara/xserver/randr/rroutput.c:410
#6 0x1c025078 in FreeClientResources (client=0x7d3f1400)
at /usr/xenocara/xserver/dix/resource.c:809
#7 0x1c02515e in FreeAllResources ()
at /usr/xenocara/xserver/dix/resource.c:826
#8 0x1c021acd in main (argc=1, argv=0xcfbc2578, envp=0xcfbc2580)
at /usr/xenocara/xserver/dix/main.c:453
(gdb)
Ideas for fixing that are of course welcome.
--
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-amd: Changes to 'master'
Someone with write access on kemper, please update the project-name variable in /git/xorg/driver/xf86-video-geode.git/hooks/update to 'xf86-video-geode' to avoid confusion. Thanks. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DeliverPropertyEvent() accessing unallocated memory
Adam Jackson wrote:
On Sat, 2008-11-22 at 13:07 +0100, Matthieu Herrb wrote:
Matthieu Herrb wrote:
Hi,
using OpenBSD's memory allocator (which has an option to fill free()'d
memory with a specific pattern) I found out that xserver 1.5.3 is
dumping core on exit.
Same problem on git's master.
This is caused by a bad pointer caused by accessing free'd memory in
DeliverPropertyEvent, because when the RRProperties are destroyed, the
associated windows have been free'd already.
So, no help on how to fix that? Should we just remove
RRDeleteAllOutputProperties() since it can't work?
It does work, when outputs are deleted at runtime. It just can't work
during server shutdown since windows are already gone, so there's
nothing to deliver events to.
Something like this maybe:
--- a/randr/rrproperty.c
+++ b/randr/rrproperty.c
@@ -59,7 +59,8 @@ DeliverPropertyEvent(WindowPtr pWin, void *value)
static void RRDeliverPropertyEvent(ScreenPtr pScreen, xEvent *event)
{
-WalkTree(pScreen, DeliverPropertyEvent, event);
+if (!(dispatchException (DE_RESET | DE_TERMINATE)))
+ WalkTree(pScreen, DeliverPropertyEvent, event);
}
void
---
Thanks for the answer. That seems to work indeed.
--
Matthieu Herrb
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: macros: Changes to 'master'
Paulo Cesar Pereira de Andrade wrote: Makefile.am | 12 +--- configure.ac | 23 --- xorg-macros.m4.in | 27 +++ xorgversion.m4| 14 ++ 4 files changed, 58 insertions(+), 18 deletions(-) New commits: commit dcbbcb582cf712e59c1474632380943bea8f1a5e Author: Peter Breitenlohner [EMAIL PROTECTED] Date: Fri Nov 14 23:06:48 2008 +0100 bump to 1.2.0 Hi, it seems you forgot to push the corresponding tag (git push --tags) back to the fd.o repositories. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Hangs at Initializing int10
Timothy S. Nelson wrote: Hi all. I'm upgrading from Fedora 6 to Fedora 10. I did a clean install of Fedora 10 and then, as the default X config didn't work, I copied across my old xorg.conf file. Naturally I had to comment out a few lines in that file. Now a word on my setup. I have two screens, one hanging off an nVidia card, and the other on a SiS card. Both of them work just fine under Fedora 6. Most of the setups with 2 graphics cards are broken in xserver 1.5.x. Anyway, after I did the steps above, I found it didn't work, so I've been trying one screen at a time. The SiS one works (unless I install the proprietary nVidia driver, so I removed that). The nVidia one doesn't work. I've tried the nv driver, the fbdev driver, and the vesa driver, all of which failed, although not always with the same error message. As nv is the one that worked with Fedora 6, that's the way I'd prefer to go (because it should be possible), but I'm open to other solutions. When I try to use the nv driver, the console appears to be hung, but it's still possible to ssh into the machine. The last entry in the log read as follows: (II) Loading /usr/lib/xorg/modules//libint10.so (II) Module int10: vendor=X.Org Foundation compiled for 1.5.3, module version = 1.0.0 ABI class: X.Org Video Driver, version 4.1 (II) NV(0): Initializing int10 Did you remove the SiS card, or make it inactive in the BIOS in some way before trying that, or is it still there as primary card? This is generally caused by the pci_device_read_rom() function in libpciaccess returning wrong data, probably because ROM and memory access to the secondary card were not enabled correctly before accessing it. The int10 code is then looping endlessly in a maze of 0xff. The last line you see is the last line in the file. I tried the NoInt10 option, and then it seemed to get a lot further, but eventually failed with Fatal server error: AddScreen/ScreenInit failed for driver 0. The vesa driver failed at the same point. I'll attach my xorg.conf and my X.0.log; any help would be appreciated. I'm not sure if Keith is planning to have this fixed in xserver 1.6. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Draft: License policy for contributors
Adam Jackson wrote: In light of the recent GLX relicensing, it was brought up to the board that our contribution policy is not really explicitly written down anywhere. The following is a licensing policy draft that's hopefully pretty uncontentious. Eventually this (or something like it) will go up on the wiki, and patches from casual contributors should be accepted with a note to the contributor of what they're agreeing to (and new developers should be pointed at it when getting their commit bit). Note that this isn't a _change_ in policy so much as an attempt to capture what we already intend. If you think this is a good opportunity to lobby for a switch to GPL or CDDL or WTFPL or whatever, that's nice and all, but please don't. I don't know what our documentation licensing stance is. MIT would keep things simple, but I don't know if it's appropriate for docs. I'm in favour of keeping the MIT license for docs too, for the sake of simplicity. At any rate, feedback greatly appreciated. --- The X.Org Foundation is dedicated to improving the open source reference implementation of the X Window System for the benefit of all. To this end, code and documentation contributions are required to be under a suitably permissive license. The preferred code license is the MIT license; the canonical form of the MIT license is here: [ insert link to version with generic THE AUTHORS rather than explicit author names ]. [ XXX doc license? ] For small changes, including patches sent through a bug tracker or mailing list, changes are assumed to be under the MIT license. If you do not agree to this, please refrain from sending us such patches in the first place, and ask to have your changes reverted if necessary. For contributions of new code and large subsystems, the code must be annotated with a copy of the MIT license (or a reference to same). Contributions under licenses other than MIT will be considered on a case by case basis, but in general are very unlikely to be accepted. Foundation developers are defined as those people with commit access to the Foundation repositories. In applying for (and accepting) developer status, you implicitly agree to these license policy terms for the Foundation works themselves. Note that your right to create derived works under different licenses is not restricted, they just won't be formal Foundation projects. For all changes, you as contributor warrant that you have the right to contribute the code in question under the license terms described here. For its part, the Foundation will work to maintain permissive grant of rights for all code and documentation in its projects. In the event that the Foundation decides to change licensing on one or more files, permission will only be sought from copyright holders as listed in the explicit Copyright statements at the top of the appropriate files. Casual contributions without assertions of copyright will not be interpreted as an assignment or relinquishing of copyright, but will be interpreted as a waiver of interest in the precise license terms. Note that under the terms of the MIT license, you effectively already waive your right to prevent use of your work under more restrictive terms (for example, under the GPLv2), and that it's quite difficult to come up with a more permissive license than MIT. The waiver in the previous paragraph is really only for the case that we somehow discover that, for example, a file was really under the Apache license and we needed to relicense it to maintain MIT-ness, or that some clause of MIT becomes unpleasantly restrictive in some jurisdiction. Sounds good. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
zaphod mode pointer problems in 1.5
Hi, in Xserver 1.5.3, when running the ati (radeon) driver in zaphod mode (ie one X screen per monitor: :0.0, :0.1) the mouse is stuck on the 1st screen. This is with the mouse driver on OpenBSD (ie no evdev/hal involved). It used to work in 1.4.x. Any idea of what kind of change can have broken that? Thanks. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Your recent changes to xorg-macros
Peter Breitenlohner wrote: Hi, in your recent commit 9ff834493ece0a0ea7d7f15c1706bab022362cc5 you have removed two warning flags for gcc 4. Looking at older gcc versions I just saw that both flags were absent in gcc-3.3.x, but present in gcc-3.4.x. These flags are eminently useful to find places that need conversion to ANSI C. Thus, please modify the test such that they are included for gcc = 3.4. The attached patch works for me on gcc 3.3 and 4.2. Can you confirm that gcc 3.4 now uses the full flags again too, before I commit it? -- Matthieu Herrb diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 9a2e26a..cbdcfa6 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -446,7 +446,7 @@ if test x$GCC = xyes ; then -Wmissing-declarations -Wnested-externs -fno-strict-aliasing \ -Wbad-function-cast case `gcc -dumpversion` in -4.*) +3.4.* | 4.*) CWARNFLAGS+= -Wold-style-definition -Wdeclaration-after-statement ;; esac ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: intel card not working when booting on another VGA card
strawks wrote: Xorg doesn't really fail to start, it just seems to mess up with the BusID directive. If I set BusID either to one or the other card with the vesa driver it will use the card defined as the primary adapter in the bios. The problem is that in xserver 1.5 and later (since the conversion to use libpciaccess), secondary cards are not enabled correctly before accessing them. You can see them in the PCI configuration space, but you get 0x for every register read from the card it self (and writes are ignored). I'm currently working on trying to fix that, but it's not straightforward since the old code did lots of weird things trying to cope with bugs in early PCI bridges implementations too. -- Matthieu Herrb smime.p7s Description: S/MIME Cryptographic Signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server: abused or buggy?
Alan Coopersmith wrote: Charles Lindsey wrote: However, let us not dismiss this POV too soon. It is usually argued that an application that suffers from such memory fragmentation should be restarted occasionally (and, given that the Xserver runs in user space, unlike in Windoze, this is not impossible, though perhaps inconvenient in some circumstances). We could also investigate using a slab allocator approach for things like data structures that are a fixed size, to keep them from ending up between pixmaps, and hopefully reducing fragmentation that way, but that's also more work no one has signed up for. (I know on Solaris there's a slab allocator version of malloc available in libumem, I don't know about libraries for other platforms though, or if Xorg would have to write it's own.) XFree86 used to have one for this purpose. It was one of the 1st victims of the X is not an operating system cleanup. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: zaphod mode pointer problems in 1.5
Bill Crawford wrote: On Wednesday 10 December 2008 06:59:13 Matthieu Herrb wrote: Hi, in Xserver 1.5.3, when running the ati (radeon) driver in zaphod mode (ie one X screen per monitor: :0.0, :0.1) the mouse is stuck on the 1st screen. This is with the mouse driver on OpenBSD (ie no evdev/hal involved). It used to work in 1.4.x. Any idea of what kind of change can have broken that? I've seen this happen when for some reason the second screen wasn't actually adjacent to the first, or when I'd resized the first screen using xrandr and then resized it back to its original size. That's something to check for too (does the server actually think the edges connect). Yes, that's what I found out too. The problem is that the edges coordinates are now computed wrong. They are now apparently set from the largest possible mode, instead from the largest mode specified in xorg.conf. So setting Virtual explicitely in xorg.conf fixes the issue, but it's still a regression since it needs more info in xorg.conf than before. Also a quick test on -current gives a segfault during screen 1 initialisation. I haven't had time to dig that further yet. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multihead Displays
Jason Gauthier wrote: All, I apologize if this is a misdirected request for assistance. I’ll gladly send it to the appropriate place. I’m attempting to multihead an Intel video card and a USB VGA adapter. You don't specify which version of the X server you're using. This may be useful since things are changing in this area... While I can get both “screens” to work with X, it’s a not a true desktop, as they are both disconnected from each other. The mouse can move back and forth, but that is all. That's the traditional (legacy) way to handle multihead in X: each head gets its own connexion :0.0, :0.1 and so on. When I attempt to enable ‘xinerama’ I get a seg fault. Currently this should indeed the way to go. If you get a segfault this is a bug and more information (Xorg.0.log for instanct) would be helpful to try to debug and fix it. From my reading, xrandr doesn’t support the USB VGA adapter. the current versions of xrandr don't support multiple cards. This is an addition planned for the future. But also the SiS usb vga driver has currently no active maintainer, so even when this gets implemented, it will take some time before it becomes available on this driver. So, I’m left wondering how to accomplish this task. Any insight is helpful! -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Paulo Cesar Pereira de Andrade wrote: hw/xfree86/loader/Makefile.am |6 -- hw/xfree86/loader/sdksyms.sh | 13 + 2 files changed, 17 insertions(+), 2 deletions(-) New commits: commit 86dc660588a615baefb1799d78a501c95a931d77 Author: Paulo Cesar Pereira de Andrade p...@mandriva.com.br Date: Tue Dec 23 18:07:54 2008 -0200 Improve sdksyms.c automatic generation (Fix #19245). Since it is already parsing cpp output, create a dependency file in the same process. This will cause sdksyms.c to be regenerated whenever a sdk header is modified. This also uses the gmake 'sinclude' directive (don't fail if included file doesn't exist). This should not cause any problems given that gmake only constructs are used in several other Makefiles. Sorry no, so far I was able to use bmake (BSD make) for all X.Org modules. What other Makefiles are using GNU make constructs? -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xauth generate and the removal of XSECURITY
Hi, is there with XACE an equivalent of the 'generate' command of xauth? -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xserver] building xserver with glx but without DRI/DRM
Dan Nicholson wrote: On Mon, Apr 13, 2009 at 5:32 PM, Rob Currey r...@graphon.com wrote: thanks dan ... what about non-linuxen? (e.g. solaris-sparc, hp-parisc, hp-ia64, etc) perhaps I don;t understand DRI enough, but I thought it was platform specific (aka either x86* or linux-only). (also likely I have it confused with something else). I'm not exactly sure what solaris does in this regard, but I believe they use dri. At least, Alan Coopersmith landed a bunch of patches in mesa to get it to work on solaris. I'm not really sure how mac handles glx, either, but it's done in xquartz. I also don't know what Solaris does, but this is what we're doing noawadys (with Mesa 7.2 and later) in OpenBSD for software only GL on architectures that don't have hardware driver. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Driver problem: Chips and Technologies F65555 HiQVPro
Moyano, Gustavo wrote: Hi all, I'm having problems setting up Xorg on my laptop. I'm migrating from FreeBSD 4.11 to FreeBSD 7.2 but seems that the chips driver does not recognize the hardware. I had no problems with FreeBSD 4.11 but 7.2 is not working. My laptop is a Toshiba Satellite 330CDS: * Processor o Intel Pentium (1.8 volt) with MMX technology, running at 266MHz o 512KB pipelined burst SRAM level 2 cache o 66MHz bus clock speed * Memory o 32MB EDO DRAM standard * Disk Drives o 4.1 gigabyte hard disk drive o 1.44MB, 3.5 diskette drive (integrated) * CD-ROM o 20X (max) CD-ROM module (integrated) * Display System o 12.1 diagonal, 800 x 600 resolution color display o Color bright dual scan o C T HiQVideo PCI (6) video controller o 2MB Video memory (EDO DRAM) o 64-bit BitBLT graphics acceleration o 66MHz local bus clock speed o Super Video Graphics Array (SVGA) compatible display I'm attaching the xorg.conf file created when I ran X -configure and the log file created when I ran X -config ... I don't know if something changed inside the driver since it was working fine on FreeBSD 4.11, which used XFree86. Could someone give me a little help, please? that sounds like bugzilla #18122. https://bugs.freedesktop.org/show_bug.cgi?id=18122 The xf86-video-chips 1.2.1 driver was not correctly converted to libpciaccess. Can you try the -current version from git, or apply the the patch from https://bugs.freedesktop.org/attachment.cgi?id=27396 ? -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-wsfb 0.3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For Xorg 7.5 Adam Jackson (1): Remove useless loader symbol lists. Alan Coopersmith (5): If using shadowfb, allocate shadow area before fbScreenInit Change XFree86 to __xservername__ in man page See Also section Remove xorgconfig xorgcfg from See Also list in man page Don't call xf1bpp or xf4bpp if they're not present (xorg-server-1.6 later) Add README with pointers to mailing list, bugzilla git repos Gaetan Nadon (2): wsfb: use XORG_CHANGELOG macro to create ChangeLog. #22611 xf86-video-wsfb: Remove unused .cvsignore file #23776 Jasper Lievisse Adriaanse (1): add some missing TRACE_EXITs, tweak and clean up comments. Matthieu Herrb (7): Makefile.am: nuke RCS Id Remove old libc wrapper stuff. now works with xserver 1.5. wsfb: update for resources/RAC API removal Call shadowRemove() in wsfbCloseScreen(). wsfb: bump for release 0.3 wsfb: fix typo in previous bump wsfb: do not forget tiny. git tag: xf86-video-wsfb-0.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-wsfb-0.3.0.tar.bz2 MD5: d6b5d25dfd61fa5113216d10a6dcbb50 xf86-video-wsfb-0.3.0.tar.bz2 SHA1: 62445e498189958dc8ad2ba2ccee048e6517fd01 xf86-video-wsfb-0.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-wsfb-0.3.0.tar.gz MD5: fd6f4b233ea540ec1139fca33d12cce4 xf86-video-wsfb-0.3.0.tar.gz SHA1: 0e54a2a65a348a9c20d024022726aecba0d187ec xf86-video-wsfb-0.3.0.tar.gz - -- Matthieu Herrb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (OpenBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSq1nSnKGCS6JWssnAQIjbwP/QVyvW0lbz1+GxMyUP8bUzJiu4kA5hCj9 HTQFYWcc40MWeGMzDJ9c3MptewC7E3B3lVMcR3qzyPtWool6TgnmoH6PdfOGG4rV uQbRWVammCnq8/oUyNQpDcHTZ961VvcqiBRjuzo6LjbiLdFfDDTDv9fbZblwqhMg jNtYGEFUy6w= =rNTo -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: touchscreens in multiscreen setups
Hi, On Thu, Dec 17, 2009 at 10:35:16PM -0800, Keith Packard wrote: From what I can see, there's no way of fixing the coordinate space issue with any driver that uses xf86XInputSetScreen today as they all convert From device to screen coordinates internally, before posting those events to the X server. And, they use cached versions of the screen size to make those transforms. That's not completely true. XInput can take care of this (although it probably suffers from the problems you mention too). I've worked on the BSD specific wscons input driver recently to update it to use modern XInput features and it doesn't need the screen dimensions anymore (except in one specific case where the calibration is done in the kernel, but this mode is currently not so great) http://www.openbsd.org/cgi-bin/cvsweb/xenocara/driver/xf86-input-ws/ I'd say tablets and touch screens should report raw device coordinates and let the X server transform them as appropriate. It'd be really cool if we could make all absolute devices report position in floating point using a [0..1] range on each axis. I think. The X server would then transform those as appropriate. I think all that would take is a new PostMotionEvent function that took doubles instead of ints; fixed drivers would use that, broken drivers would continue to report coordinates as they do today. Not really necessary: X Input has the min/max values for each axes and can do the computation for the driver. But why not ? xf86InputSetScreen comes into play mostly when it comes to figuring out if this feature is possible to bring back without breaking the ABI. If we can re-use it in a sensible manner, great. Yeah, I don't see it as useful; the drivers are using the target screen size to scale their data. Not helpful. if you modify the coordinates, you break raw events though and lose precision on the screen you're restricted to. I think this needs to be tied to miPointerSetScreen and possibly the pointer accel code, but that includes a fair deal of speculation as well. I don't see how miPointerSetScreen relates; most X servers have only one screen today. If we break the API, it doesn't matter. It just currently the only callback to upper layer beside the post event one to tell the X server to update any data related to the current state of the input driver. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: touchscreens in multiscreen setups
On Thu, Dec 17, 2009 at 09:27:07PM -0800, Keith Packard wrote: On Fri, 18 Dec 2009 15:04:48 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: there's two parts to it: - xf86InputSetScreen seems broken, this should be fixed in the server. though it's probably optimised for the Xinerama scenario, I think it should be possible to set it up for randr output or CRTC tracking in a similar manner. It would need to be tied to an output, not a crtc. And, what we'd need to do is let the input device know which output it is associated with, and then provide a helper function to translate coordinates relative to that output. That could deal with output transforms as well. I don't see how xf86XInputSetScreen has much to do with this though, other than having that be used as a hint to go lookup the output property in the config file? For touchscreens you want to tie it to the particular output it's physically bound to in (almost) all cases. And in multi-head setups you need another pointer for heads without associated touchscreens. Tablets may be a bit different: you may want to use it as the only input device, covering all the screen. (Although the geometry will probably be awfully distorded). Other people, like graphic designers will prefer to have the tablet restricted to the output bound to the head where their main canvas is displayed and use a second input driver to drive the 2nd head where the menus with all tools are displayed. From the configuration point of view, in most cases the underlaying driver knows if it's a touchscreen or a tablet and can choose a reasonable default, but the configuration should be modifiable on the fly. -- Matthieu Herrb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XDS 2010, September 16-18 in Toulouse, France
The X Developers' Summit 2010 will be held this year in Toulouse, from September 16 to 18. We've setup a page on the event on the X.Org wiki at http://www.x.org/wiki/Events/XDS2010 Call for papers --- If you would like to present a talk on on-going work on X development, or presenting innovative uses of the X.Org technology, please submit your proposal on the wiki http://www.x.org/wiki/Events/XDS2010/Program, under 'Ideas', before July 31th. Attending - As always attending the conference will be free. Registration is on http://www.x.org/wiki/Events/XDS2010/Attendees is required though. You will find practical informations on the main wiki page for the event to organize your travel. Looking forward to see you in Toulouse. -- Matthieu Herrb On behalf of X.Org Foundation Board ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XDS 2010, September 16-18 in Toulouse, France
The X Developers' Summit 2010 will be held this year in Toulouse, from September 16 to 18. We've setup a page on the event on the X.Org wiki at http://www.x.org/wiki/Events/XDS2010 Call for papers --- If you would like to present a talk on on-going work on X development, or present innovative/original uses of the X.Org technology, please submit your proposal on the wiki: http://www.x.org/wiki/Events/XDS2010/Program under 'Ideas', before Aug 16th. Attending - As always attending the conference will be free. Registration is on http://www.x.org/wiki/Events/XDS2010/Attendees is required though. You will find practical informations on the main wiki page for the event to organize your travel. If you already registered on the wiki as 'tentative' and either have since confirmed your travel, or have been forced to cancel it, please update your information. Looking forward to see you in Toulouse. -- Matthieu Herrb On behalf of X.Org Foundation Board -- Matthieu Herrb pgpCA59qtTg9p.pgp Description: PGP signature ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [ANNOUNCE] xf86-video-glide 1.1.0
On Tue, Nov 09, 2010 at 08:05:21AM -0500, Gaetan Nadon wrote: On Tue, 2010-11-09 at 04:20 +0100, Guillem Jover wrote: build: Use LT_INIT instead of deprecated AC_PROG_LIBTOOL and AC_DISABLE_STATIC LT_INIT requires libtool v2 whereby xorg lowest common denominator is v1.5. I suspect that in real life almost everyone uses v2. If I understand correctly, when configured with v2, libtool copies a handful of v2 macros in the m4 directory (only if available). This allows a system with v1.5 to use the v2 macros. I am considering upgrading all of xorg to libtool v2 (only formalizing the current situation). I am interested in the feedback you may get from builders on that matter. For now OpenBSD is still using libtool 1.5. The OpenBSD port people have come up with a replacement for libtool, but for now they don't have the 'libtoolize' and macros support ready, so the ability of running autoreconf with GNU libtool 1.5 is still needed, at least for a few more months (lets say until Xorg 7.7) PS: for xf86-video-glide it doesn't matter, since this driver is Linux specific. -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: latest git xserver without hal causes Hotplugging to be a bit tricky
On Sat, Nov 27, 2010 at 10:36:21AM +0100, Rémi Cardona wrote: Le 27/11/2010 05:24, Justin Mattock a écrit : Section ServerFlags Option AutoAddDevices False EndSection Remove that. You've just disabled input hotplugging. is there a new option that I need to add to xorg.conf in order to startx and have radeon work right as well as the mouse and keyboard? or is this dependant on hal and/or device manager? (machine is a macbook pro) Install xf86-input-evdev. That's the 'new' input driver everyone should be using, it handles pretty much everything: keyboards, mice, trackpads, etc. You mean everyone running Linux... Once that works, you may want to install a specific driver like -synaptic (most touchpads) or -wacom (tablets), if you have such hardware. The -kbd and -mouse drivers are still maintained but not recommended, as they completely bypass the kernel's input stack. These are still the recommended drivers for non-linux systems. -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: how can one build X without libxcb, or libxcb without python, or python without tcl/tk, or tcl/tk without X ?
On Mon, Feb 07, 2011 at 10:40:44AM -0500, Peter Harris wrote: On 2011-02-07 10:31, matti christensen wrote: i am afraid and don't like snakes. i downloaded libX 1.3.2 i really hope you get rid of such dependency to something that may or may not be in one's system = keep to basics Python isn't my favourite language either, but it's much better than the previous XSLT implementation. I don't think it's too much of a burden to expect python on a build machine. It's a pain on *BSD where python is not part of the base system. To be able to let users build X on a base system with no additional packages installed, we provide pre-generated c-code for xcb. So only developers who want to touch the xml files need to install python. -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Alignment error in libXi
On Thu, Mar 24, 2011 at 11:51:32PM -0700, Jeremy Huddleston wrote: Don't feel too bad. I missed it too and bugged Peter about it before I pushed the release ;) Unfortunatly, as Peter forsaid it, there are other issues. I'm currently fighting with the code for XISelectEvents(). It uses Data32() to send a xXIEventMask structure. This is very wrong and fails miserablily on sparc64, for at least 2 reasons: 1. Data32() suffers from the infamous 'use unsigned long for 32 bits data' API mis-design, so on 64 bits machines one can't pass a pointer to a 32 bit only data to Data32(): it has one chance over 2 to be mis-aligned, and will read 4 extra random bytes on the stack. 2. since xXIEventMask contains two uint_16 values, which are not properly swapped, this will not work across client/server with different endianness. This can all be seen whil trying Gtk+3's gtk3-demo on an OpenBSD/sparc64 machine, but probably on other 64 bits big endian machines too. For now I have the ugly patch below. Any better suggestion ? And there are other issues... --- src/XISelEv.c 4 Sep 2010 10:17:03 - 1.2 +++ src/XISelEv.c 27 Mar 2011 15:09:31 - @@ -32,6 +32,7 @@ in this Software without prior written a #include stdint.h +#include X11/Xarch.h #include X11/Xlibint.h #include X11/extensions/XI2proto.h #include X11/extensions/XInput2.h @@ -46,6 +47,7 @@ XISelectEvents(Display* dpy, Window win, XIEventMask *current; xXISelectEventsReq *req; xXIEventMask mask; +unsigned long long_mask; int i; int len = 0; int r = Success; @@ -83,7 +85,12 @@ XISelectEvents(Display* dpy, Window win, * and they need to be padded with 0 */ buff = calloc(1, mask.mask_len * 4); memcpy(buff, current-mask, current-mask_len); -Data32(dpy, mask, sizeof(xXIEventMask)); +#if X_BYTE_ORDER == X_BIG_ENDIAN + long_mask = mask.deviceid 16 | mask.mask_len; +#else + long_mask = mask.mask_len 16 | mask.deviceid; +#endif + Data32(dpy, long_mask, sizeof(xXIEventMask)); Data(dpy, buff, mask.mask_len * 4); free(buff); } -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why is sizeof(XID)==8 on AMD64?
On Mon, Mar 28, 2011 at 04:11:35PM +0200, Clemens Eisserer wrote: Hi, I just ran in a couple of bugs because my code assumes sizeof(XID)==4 on all platforms which doesn't seem to hold on AMD64. Whats the reason for XID to be 8bytes (unsigned long) on AMD64, I thought an x-id (in protocol sence) is defined as 4 bytes anyway? Will Xlib/xcb ever return values which don't fit in 4 bytes? If so, I guess I have to change a lot of java-code which assumes this - otherwise I would only need to adapt the Java--Xlib interface a bit. Thank you in advance, Clemens This is a mistake done 25 years ago or so. It's hard to justify it, but it is so. A number of things that are 32 bits on the wire are represented as 64 bits long at the API level on LP64 machines. You have to read the API manual pages carefully and follow them. Changing the APIs now would break too many things, an no one as ever considered doing a new major revisition of all those APIs. The most commonly mis-used API is probably XChangeProperty(), but others are similarly difficult. We also just discovered a number of issues in the XI2 API. -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Why is sizeof(XID)==8 on AMD64?
On Mon, Mar 28, 2011 at 04:47:18PM +0200, Clemens Eisserer wrote: Hi Matthieu, Thanks for your explanation =) This is a mistake done 25 years ago or so. It's hard to justify it, but it is so. A number of things that are 32 bits on the wire are represented as 64 bits long at the API level on LP64 machines. Is it considered more or less safe to store those 64-bit XIDs in 32bit variables? Since they are 32 bits values at the protocol level, yes. If not really required I would prefer not to change all my code. But be careful everytime you pass your 32 bit variables to X functions that expect 64 bit values, especially when a pointer to such a variable is used (like in XChangeProperty() that I mentionned above). On little endian architectures with weak alignment constaints passing a pointer to a 32 bit only value won't harm too much since the low 32 bits will be used as expected. But on big endian architectures, it will use the the 32 higher bits of the value you're pointing to, which are not well defined... And if your architecture as strict aligment constraints for 64 bits values, passing a pointer to a 32 bit data has great chances to produce an unaligned access error. -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
sticky xkb options ?
Hi, In order to keep the oldctrl+alt+backspace sequence killing X by default, I'm looking for the best place to place the configuration option. I'd like to put it in /etc/X11/xorg.conf.d/00-killserver or similar. Unfortunatly, at least with xserver 1.9 or 1.10, 'Option XkbOption terminate:ctrl_alt_bksp' doesn't stick. Any other 'Option XkbOption ...' parsed later will clear the already set options. The same is true for any initialisation done inside the xserver code itself via add_option(). Is there a way to set a sticky xkbOption ? -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Fw: sticky xkb options ?
On Sat, Aug 20, 2011 at 11:07:07AM -0700, Alan Coopersmith wrote: On 08/20/11 11:02, Chris Robinson wrote: - Forwarded Message - *From:* Chris Robinson fabricat...@yahoo.com *To:* Matthieu Herrb matthieu.he...@laas.fr *Sent:* Sunday, 21 August 2011 4:01 AM *Subject:* Re: sticky xkb options ? Hi, Try: Section “ServerFlags” Option “DontZap” “yes” EndSection in xorg.conf I just verified this with Slackware. Then slackware is either shipping years out-of-date bits or has otherwise patched this locally. http://who-t.blogspot.com/2009/04/zapping-server.html Anyways, this doesn't help me. The terminate:ctrl_alt_bksp option is needed in addtion to making sure DontZap is false (double negation). And sticky xkboptions could be useful for other options too, given that a way to reset them explicitely also exist. Thoughts? -- Matthieu Herrb ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
X.Org security advisory: xserver locking code issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 X.Org security advisory, October 18, 2011 xserver locking vulnerabilities CVE IDs: CVE-2011-4028 CVE-2011-4029 Description - --- Two vulnerabilities have been discovered in the code handling the X server lock, that forbids two X servers from serving the same display simultaneously. o CVE-2011-4028 : File disclosure vulnerability: It is possible to deduce if a file exists or not by exploiting the way that Xorg creates its lock files. This is caused by the fact that the X server is behaving differently if the lock file already exists as a symbolic link pointing to an existing or non-existing file. o CVE-2011-4029 : File permission change vulnerability: It is possible for a non-root user to set the permissions for all users on any file or directory to 444, giving unwanted read access or causing denies of service (by removing execute permission). This is caused by a race between creating the lock file and setting its access modes. Affected Versions - - All X.Org Xserver versions are vulnerable to CVE-2011-4028 when running with root privileges. X.Org Xserver version 1.4 and later are vulnerable to CVE-2011-4029 when running with root privileges. Workaround - -- Removing the setuid bit on the Xorg binary (and using a display manager to start it with controlled parameters) makes the issues harder to exploit, but not impossible. Fix - --- Those issues have been fixed by the following two git commits: CVE-2011-4028: 6ba44b91e37622ef8c146d8f2ac92d708a18ed34 http://cgit.freedesktop.org/xorg/xserver/commit/?id=6ba44b91e37622ef8c146d8f2ac92d708a18ed34 CVE-2011-4029: b67581cf825940fdf52bf2e0af4330e695d724a4 http://cgit.freedesktop.org/xorg/xserver/commit/?id=b67581cf825940fdf52bf2e0af4330e695d724a4 A fix of this vulnerability will be included in xserver 1.11.2 and xserver 1.12. The X.Org Foundation thanks vladz (http://vladz.devzero.fr) for bringing this issue to our attention and helping testing the fixes. - -- Matthieu Herrb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBTp2SLPee5zRnIoYlAQJRvQf8D1GyyOVHR1KBUUP7L2PiobbLRp1JXPar iOm24Uk+4vH6arnx1zdmsdCkLVmtJxi3Y6KYgv07NOQUstd1s5rifPiFxCek8T2b 5TNFo1EIxbESh6d29VNi6rkRigK6WVFQiqJj3MbYA4XBqoibi48FG5JQYrjVG6ki lPmX4pT2pOCYsSQGJPbRNr7Ra4GWj0lYX1ZC72aD1/kFn1I9t04QoPdW7YpG90eI s1VI8JpqdsRdyQ88AQTytLSKYAveEY5RuouOOe8KfIljtLW+elw5LzBZoE60WVB4 ltZElUNI8neEgeawHm5TnWhvq3ieU7LS5mMZqfDQaZfvc95dS4YdLA== =LvrS -END PGP SIGNATURE- ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] various integer overflow vulnerabilites in xserver, libX11 and libXfont
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 X.Org security advisory, April 3rd, 2007 Multiple vulnerability in X server, libXfont and libX11 CVE IDs: CVE-2007-1003 CVE-2007-1351 CVE-2007-1352 CVE-2007-1352 Overview Lack of validation of parameters passed to the X server and libX11 by client application can lead to various kinds of integer overflows or stack overflows that can be used to overwrite data in the X server memory. Vulnerabilities details * CVE-2007-1003 XC-MISC extension integer overflow iDefense Lab security researchers discovered that the parameter used for ALLOCATE_LOCAL in ProcXCMiscGetXIDList() is computed from an expression using a client-provided value that can be arbitrarily big. This can lead to an integer overflow in the evaluation of the expression or, when ALLOCATE_LOCAL() is using alloca(), to memory corruption if the parameter is big enough to fall out of the stack. The vulnerable request is only available to an already authenticated client of the X server . * CVE 2007-1351 bdf font parsing integer overflow iDefense Lab security researchers discovered that the BDF font parsing code in libXfont lack some input validation checks, permitting a specially crafted font in the BDF format to trigger an integer overflow in the parameter to a call to xalloc() in the bdfReadCharacters() function in bdfread.c, leading to memory corruption. An attacker needs to already have access to the system either as an authenticated client of the running X server, or with the ability to (re)start the X server. This vulnerability also affects the Freetype 2 library up to an including 2.3.2 . Refer to the Freetype web site to obtain a patch. * CVE 2007-1352 fonts.dir file parsing integer overflow iDefense Lab security researcher have identified that the code parsing the fonts.dir file in libXfont lacks validation of the initial number of fonts declared in this file. This can be used to trigger an integer overflow in the computation of the parameter to xalloc() in the FontFileInitTable() function, leading to memory corruption. An attacker needs to already have access to the system either as an authenticated client of the running X server, or with the ability to (re)start the X server. * CVE 2007-1667 libX11 XInitImage input validation Sami Leides has reported to the Debian BTS that some manually crafted images can lead to memory corruptions in libX11, due to incomplete input validation in XInitImage(), in ImUtils.c. It has be demonstrated that at least xwud and ImageMagick can be used to trigger calls to XInitImage() with incorrect parameters when viewing a malicious image. Other image viewing programs can probably be used too. This vulnerability can be exploited by having the user already connected to the X server to launch a viewer on the malicious image. Affected versions All released X.Org versions of xserver, libX11 and libXfont are vulnerable to the respective problems. Other X window system implementations based on the X11R6 sample implementation are probably vulnerable too. Fix Apply one of the following patches X.Org 7.2 http://xorg.freedesktop.org/archive/X11R7.2/patches/ MD5: d52da02163cd401b99b6e3a08d7ff068 xorg-libX11-1.1.1-xinitimage.diff SHA1: a0f904115ad9dc441bebcf2f8267f9751322b727 xorg-libX11-1.1.1-xinitimage.diff MD5: 76e3330c9bace76318e096b3c2182101 xorg-libXfont-1.2.7-bdf-fontdir.diff SHA1: 3e57aca6215e1212e53b1a3b1d243916ac7fa703 xorg-libXfont-1.2.7-bdf-fontdir.diff MD5: 0fa07a8fb2bc14fa01fc29e42b89c59e xorg-xserver-1.2.0-xcmisc.diff SHA1: 3557cbe23be6912106ed7220d95301311fb93a26 xorg-xserver-1.2.0-xcmisc.diff These patches can be applied to earlier versions of X.Org too with a few manual tweaks. Thanks Sean Larsson of iDefense Labs discovered the XC-MISC vulnerability and provided sample code and advices in fixing it. - -- Matthieu Herrb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRhLOpnKGCS6JWssnAQKphwQAi+8ofGsHiPpYuI01iIxHuilvJobOi+UT yPShf25RJa4JImUOyZ2KMELU0cpoy1qYphStsLgnxXt5rf9UpG1HRoHaLTNRP6d4 iP7Val2uuf8K6aI2EibyohF87Fv9OcC5aMpHLoGBALrg530qA48cqdRIeYvDgP19 v4VuQmBsqIQ= =WuJc -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xsetroot 1.0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Balmer (1): Typo, it's xsetroot, not setroot. Matthieu Herrb (5): - renamed .cvsignore - .gitignore - Replace static ChangeLog with disthook to generate from git log Change xsetroot_CFLAGS to AM_CFLAGS to avoid automake-1.10 warning Add option to check code with lint/sparse/etc. bump version git tag: xsetroot-1.0.2 http://xorg.freedesktop.org/archive/individual/app/xsetroot-1.0.2.tar.bz2 MD5: 9af7db9f3052aef0b11636720b3101dd xsetroot-1.0.2.tar.bz2 SHA1: 55fbfc74d443ebc5bc1bdb3d4276c0b2d62e7e4a xsetroot-1.0.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xsetroot-1.0.2.tar.gz MD5: b6c6bfc64ed67664865d58e343a37761 xsetroot-1.0.2.tar.gz SHA1: b6e016f48e4fbb0d0344d5c8291e733b5a1ceb98 xsetroot-1.0.2.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (OpenBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRrwqWnKGCS6JWssnAQKpYAQAoQvlE68FyB3fr7TOeUzeuxyogaaRZlJz UoLlt7gZhMPXOIxMLmB5vxI3i9o2V2phHI46AyEuaknBf5ISZL7YX2vNu+fk2Ktu EhaR7kFZPuMawvxZPQbexNlpPDh94n5uJt5rhm2fZFbrj3RQEFucMw+vNfRNZshe qnC0pOi5x10= =uAy0 -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-wsfb 0.3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For Xorg 7.5 Adam Jackson (1): Remove useless loader symbol lists. Alan Coopersmith (5): If using shadowfb, allocate shadow area before fbScreenInit Change XFree86 to __xservername__ in man page See Also section Remove xorgconfig xorgcfg from See Also list in man page Don't call xf1bpp or xf4bpp if they're not present (xorg-server-1.6 later) Add README with pointers to mailing list, bugzilla git repos Gaetan Nadon (2): wsfb: use XORG_CHANGELOG macro to create ChangeLog. #22611 xf86-video-wsfb: Remove unused .cvsignore file #23776 Jasper Lievisse Adriaanse (1): add some missing TRACE_EXITs, tweak and clean up comments. Matthieu Herrb (7): Makefile.am: nuke RCS Id Remove old libc wrapper stuff. now works with xserver 1.5. wsfb: update for resources/RAC API removal Call shadowRemove() in wsfbCloseScreen(). wsfb: bump for release 0.3 wsfb: fix typo in previous bump wsfb: do not forget tiny. git tag: xf86-video-wsfb-0.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-wsfb-0.3.0.tar.bz2 MD5: d6b5d25dfd61fa5113216d10a6dcbb50 xf86-video-wsfb-0.3.0.tar.bz2 SHA1: 62445e498189958dc8ad2ba2ccee048e6517fd01 xf86-video-wsfb-0.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-wsfb-0.3.0.tar.gz MD5: fd6f4b233ea540ec1139fca33d12cce4 xf86-video-wsfb-0.3.0.tar.gz SHA1: 0e54a2a65a348a9c20d024022726aecba0d187ec xf86-video-wsfb-0.3.0.tar.gz - -- Matthieu Herrb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (OpenBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSq1nSnKGCS6JWssnAQIjbwP/QVyvW0lbz1+GxMyUP8bUzJiu4kA5hCj9 HTQFYWcc40MWeGMzDJ9c3MptewC7E3B3lVMcR3qzyPtWool6TgnmoH6PdfOGG4rV uQbRWVammCnq8/oUyNQpDcHTZ961VvcqiBRjuzo6LjbiLdFfDDTDv9fbZblwqhMg jNtYGEFUy6w= =rNTo -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
XDS 2010, September 16-18 in Toulouse, France
The X Developers' Summit 2010 will be held this year in Toulouse, from September 16 to 18. We've setup a page on the event on the X.Org wiki at http://www.x.org/wiki/Events/XDS2010 Call for papers --- If you would like to present a talk on on-going work on X development, or presenting innovative uses of the X.Org technology, please submit your proposal on the wiki http://www.x.org/wiki/Events/XDS2010/Program, under 'Ideas', before July 31th. Attending - As always attending the conference will be free. Registration is on http://www.x.org/wiki/Events/XDS2010/Attendees is required though. You will find practical informations on the main wiki page for the event to organize your travel. Looking forward to see you in Toulouse. -- Matthieu Herrb On behalf of X.Org Foundation Board ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
XDS 2010, September 16-18 in Toulouse, France
The X Developers' Summit 2010 will be held this year in Toulouse, from September 16 to 18. We've setup a page on the event on the X.Org wiki at http://www.x.org/wiki/Events/XDS2010 Call for papers --- If you would like to present a talk on on-going work on X development, or present innovative/original uses of the X.Org technology, please submit your proposal on the wiki: http://www.x.org/wiki/Events/XDS2010/Program under 'Ideas', before Aug 16th. Attending - As always attending the conference will be free. Registration is on http://www.x.org/wiki/Events/XDS2010/Attendees is required though. You will find practical informations on the main wiki page for the event to organize your travel. If you already registered on the wiki as 'tentative' and either have since confirmed your travel, or have been forced to cancel it, please update your information. Looking forward to see you in Toulouse. -- Matthieu Herrb On behalf of X.Org Foundation Board -- Matthieu Herrb pgpJTJfx1wJhL.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
