Re: server crash on linux-mips
On Mon, Feb 17, 2003 at 06:55:47PM -0500, Mark Vojkovich wrote: Does anyone see any reason why I shouldn't change ShadowFBInit to pass FALSE? This seems to be produce the original behavior. Passing TRUE certainly doesn't. So what exactly is the point of fbIsVirtual at all? The only other effect seems to wrap ps-Composite. Regards, -- Guido ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Next make install error with the 4.3 preversion
Hi, here I'm again: got that optimization prob solved and now ran into the following prob: [...] install in programs/xrandr done make[3]: Leaving directory `/root/xfree-cvs/xc/programs/xrandr' installing in programs/xcursorgen... make[3]: Entering directory `/root/xfree-cvs/xc/programs/xcursorgen' gcc -m32 -O3 -fomit-frame-pointer -march=pentium4 -ansi -pedantic -pipe -I../.. -I../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -c -o xcursorgen.o xcursorgen.c rm -f xcursorgen gcc -m32 -o xcursorgen -O3 -fomit-frame-pointer -march=pentium4 -ansi -pedantic -pipe -L../../exports/lib xcursorgen.o -lXcursor -lXext -lX11 -lpng -lm -Wl,-rpath-link,../../exports/lib install -c xcursorgen /usr/X11R6/bin/xcursorgen + mkdir -p /usr/X11R6/lib/X11/icons/default install -c index.theme /usr/X11R6/lib/X11/icons/default/index.theme installing in programs/xcursorgen/redglass... make[4]: Entering directory `/root/xfree-cvs/xc/programs/xcursorgen/redglass' LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/xcursorgen X_cursor.cfg X_cursor /bin/sh: ../../../exports/bin/xcursorgen: No such file or directory make[4]: *** [X_cursor] Error 1 make[4]: Leaving directory `/root/xfree-cvs/xc/programs/xcursorgen/redglass' make[3]: *** [install] Error 2 make[3]: Leaving directory `/root/xfree-cvs/xc/programs/xcursorgen' make[2]: *** [install] Error 2 make[2]: Leaving directory `/root/xfree-cvs/xc/programs' make[1]: *** [install] Error 2 make[1]: Leaving directory `/root/xfree-cvs/xc' make: *** [install] Error 2 Ok, exports/bin/xcursorgen is not there... If I copied it by hand from programs/xcursorgen to the location where it is expected, make install went through the whole process w.o. errors Heh and this error also occurs on my laptop without any optimization flags ... ;-) Is it a bug or a feature of only my linux installation? regards micha -- Michael Wahlbrink| Woeschhalde 32 | 78052 Villingen Schwenningen [EMAIL PROTECTED]| Germany ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: make install error with 4.3 preversion from cvs
On Mon, 17 Feb 2003 14:29:06 -0500 (EST) Bryan Liesner [EMAIL PROTECTED] wrote:
On Mon, 17 Feb 2003, Michael Wahlbrink wrote:
Hi,
I don't know if this is a known problem or what's to do now. On my linux system
(gcc-3.2.2)
I can make with no problems, but when I try to install I get the
following error
root:~/xfree-cvs/xc# make install
[...]
gcc -m32 -c -ansi -pedantic -pipe -I../include -I../../../include
-I../../../include/GL -I../../.. -I../../../exports/include
-Dlinux -D__i386__
-D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE
-D_BSD_SOURCE -D_SVID_SOURCE
-D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DNDEBUG -O3
-fomit-frame-pointer -march=pentium4
-mfpmath=sse mipmap.c -o unshared/mipmap.o
mipmap.c: In function `halve1Dimage_float':
mipmap.c:1268: unable to find a register to spill in class `FLOAT_REGS'
mipmap.c:1268: this is the insn:
(insn 111 109 114 (set (subreg:SF (reg/v:DI 22 rxmm1 [73]) 0)
(float:SF (reg:DI 0 rax [89]))) 170 {*floatdisf2_i387_only} (insn_list 108
(nil))
(expr_list:REG_DEAD (reg:DI 0 rax [89])
(nil)))
The make did fail... On install, it tried to rebuild the bits that
failed during the make.
Get rid of the -O3 and the -march=pentium4. You're asking for trouble with those
optimizations.
Try using just -O and recompile.
Ok after a few tests and compiles i get it, that it was the -mfpmath=sse option which
leed there to some confused registers
but then I got the next make install Problem see mail in a new thread
thanks a lot for your help
regards
micha
--
Michael Wahlbrink| Woeschhalde 32
| 78052 Villingen Schwenningen
[EMAIL PROTECTED]| Germany
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
I'm stuck: font-related crash with current CVS
Mike has reported to me a crash with the new FreeType backend and the Caslon fonts included with SuSE. (Mike, could you be so kind as to follow up with a stable URL for the fonts?) I'm stuck. The problem doesn't happen with xfs, and it doesn't happen with a monolithic server. So it must be in some way related to the module loader. A couple of hours of printf-based debugging got me to the point where the crash happens within the FreeType library. I've been unable to make the loader-aware debugger work on my system (crashes at startup, and the osource won't build). If anyone can help, please do. (David, does that count as a release-critical bug?) Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
MF Caslon fonts (same problem): Hold on... I'm seeing a crash with the Caslon fonts. Are you seeing something else? Juliusz ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I'm stuck: font-related crash with current CVS
Around 14 o'clock on Feb 18, Mike FABIAN wrote: On my machine there is no crash neither with the Caslon fonts nor with the Omegaserif fonts, only an error message when trying to open the font: The version of TrueType in XFree86 is catching an error inside the Unicode cmap tables when attempting to load them. This is handled inside FreeType with setjmp/longjmp, which I believe to be the source of the segfaults. And, it results in a BadValue error with a bogus error Value in loading the fonts otherwise. Using FreeType 2.1.3 corrects the cmap loading problem, but I'm afraid we'll still have segfaults from the setjmp/longjmp issue. -keith ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Sun, 2003-02-16 at 16:36, Mark Vojkovich wrote: I don't really know what the point of fbIsVirtual was. Apps that use ShadowFBInit need to repaint when entering the VT. We didn't have the EnableDisableFBAccess stuff when I wrote shadowfb and the refresh at EnterVT was to catch the copy from the old root window backing pixmap. With EnableDisableFBAccess handling exposures, it shouldn't be needed anymore but we definitely don't want to block EnableDisableFBAccess like the code is doing. It seems like having ShadowFBInit call ShadowFBInit2 with FALSE is the correct behavior. Experimentation shows this to remove the corruption. The previous shadowfb code blocked EnableDisableFBAccess and updated on VT switching. Since the code looked stale (I couldn't find where the screen got stored in the backing pixmap anywhere), I disabled it for the vmware driver, but since I didn't have a way to test the other clients of shadowfb, I preserved the old behavior for them. If having ShadowFBInit call ShadowFBInit2 with FALSE works for all clients, then the fbIsVirtual flag can be removed entirely; the only caller of ShadowFBInit2 is vmware.c, and it passes in FALSE. -- Nolan ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Mon, 2003-02-17 at 14:11, Alan Hourihane wrote: shadowfb.h says about ShadowfbInit2: * It also allows you to specify that you * actually do have a real framebuffer (as opposed to just some malloc'd space * in memory) by passing FALSE to fbIsVirtual. But when I pass TRUE (since I only have a virtual fb and can't access the newports fb directly) it doesn't work. I have to pass FALSE. Am I missing something here? Not that I can see. I was hoping that Nolan Leake from VMware can shed some light on this. Sorry; I based that comment and code on the old comment /* nothing happens here; nothing touches the real frame buffer */. Since X no longer saves the contents of the screen during VT switching, I believe the EnableDisableFBAccess wrapper and the fbIsVirtual flag can be eliminated. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Tue, Feb 18, 2003 at 10:49:58 -0800, Nolan Leake wrote: On Sun, 2003-02-16 at 16:36, Mark Vojkovich wrote: I don't really know what the point of fbIsVirtual was. Apps that use ShadowFBInit need to repaint when entering the VT. We didn't have the EnableDisableFBAccess stuff when I wrote shadowfb and the refresh at EnterVT was to catch the copy from the old root window backing pixmap. With EnableDisableFBAccess handling exposures, it shouldn't be needed anymore but we definitely don't want to block EnableDisableFBAccess like the code is doing. It seems like having ShadowFBInit call ShadowFBInit2 with FALSE is the correct behavior. Experimentation shows this to remove the corruption. The previous shadowfb code blocked EnableDisableFBAccess and updated on VT switching. Since the code looked stale (I couldn't find where the screen got stored in the backing pixmap anywhere), I disabled it for the vmware driver, but since I didn't have a way to test the other clients of shadowfb, I preserved the old behavior for them. If having ShadowFBInit call ShadowFBInit2 with FALSE works for all clients, then the fbIsVirtual flag can be removed entirely; the only caller of ShadowFBInit2 is vmware.c, and it passes in FALSE. O.k. Thanks Nolan. I've just removed that code from the CVS. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: FW: [Xpert]2 mice - 2 pointer ?!?
On Tue, 18 Feb 2003, Rob Taylor wrote: Here's a mail that's been sitting in my outbox for a while: its' still relevent so forwarding to Xfree86 Devel. -Original Message- From: Rob Taylor [mailto:[EMAIL PROTECTED]] Sent: 04 February 2003 13:49 To: [EMAIL PROTECTED] Subject: RE: [Xpert]2 mice - 2 pointer ?!? I'm replying to this a bit late on in the day, but i thought i'd give a more concrete example where more than one on-screen pointer is needed. We have a product that can have up to 4 touch screens and has a track-ball controlled pointer. Iften people operate the product in a two-handed manner, and occasionally more than one operator will use the product at a given time. the upshot of this is that ideally there would be a pointer for the trackball that isn't effected by touchscreen presses, and separate invisible pointers for each of the touchscreens. The setup is currently impossible in Xfree86. I'm beginning to understand what you want here. I don't think you really need pointers for the touch-screens; just events when they are pressed. I haven't checked, but I think that one of the standard extensions (perhaps XInputExtension) should be able to do that for you. At some level this isn't really a mouse click; if you want standard apps to behave as if they received a mouse-click, then you want a wrapper app to convert touch-screen presses into synthetic events sent to the standard app (perhaps indirectly via the window manager). Another concrete example is when implementing a collaborative decktop in whcih you want a separate pointer for each of the users remotely viewing that desktop. Are you going to let them type into different windows at the same time ? That really would be two pointers. However I think that should be done by the collaboration software, not by X. I'm not convinced that two pointers are a good idea on a collaborative desktop, forcing the participants to share a pointer helps them to share their focus. Without it they could easily each do their own thing and stop watching what the other one is doing: a good way to reduce the efficiency of the collaboration ? VNC draws a dot cursor to indicate when the pointers at the two ends are out of sync, to make it clear to the remote user that the local user hasn't yet seen what the remote user is pointing at. And don't forget that most current graphics cards only have one hardware cursor. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: issues with trident card
Alan, I've been able to track down the problem a bit further : The problem is related to the height of the window, not the width. And the limit is exactly 200 pixels. For any width, a height = 200 pixels doesn't show the problem. But if height 200, the the problem shows (the problem I'm talking about is a screen wide line located on the top of the output Xv window) Hope that helps, Cheers, Olivier. On Sun, 2003-02-16 at 00:07, Olivier Fourdan wrote: Hi Alan, On Sat, 2003-02-15 at 12:44, Alan Hourihane wrote: Have a go at trying to fix it with changing the line above. Well, I guess I've been too fast here. The problem doesn't come from the code I cited, sorry. Actually, it seems to be related to the size of the output (or maybe a ratio between the source and destination sizes ?) Xv window, but not the way I thought it was... Sorry about this. It seems I'm not able to track down what is the exact limit for the problem to show up. It's probably something like a 600x400 window. I've added traces, all arround and I've also tried to remove the VID_DOUBLE_LINEBUFFER_FOR_WIDE_SRC flag and it has no effect. Amazingly enough, I have 1 video that doesn't show the problem, whatever the size of the output window (maybe RGB not showing the problem while YUV does ? I don't know if that makes any sense). All other videos I have show the problem. Any clue where I should look next ? Cheers, -- Olivier Fourdan [EMAIL PROTECTED] http://www.xfce.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: issues with trident card
Alan, Err... no. 200 was the height of the source window in my test app. So real limit is the height of the source window. If the output window is higher than the source window, the problem arises, otherwise if doesn't show. Cheers, Olivier. On Tue, 2003-02-18 at 22:34, Olivier Fourdan wrote: Alan, I've been able to track down the problem a bit further : The problem is related to the height of the window, not the width. And the limit is exactly 200 pixels. For any width, a height = 200 pixels doesn't show the problem. But if height 200, the the problem shows (the problem I'm talking about is a screen wide line located on the top of the output Xv window) Hope that helps, Cheers, Olivier. On Sun, 2003-02-16 at 00:07, Olivier Fourdan wrote: Hi Alan, On Sat, 2003-02-15 at 12:44, Alan Hourihane wrote: Have a go at trying to fix it with changing the line above. Well, I guess I've been too fast here. The problem doesn't come from the code I cited, sorry. Actually, it seems to be related to the size of the output (or maybe a ratio between the source and destination sizes ?) Xv window, but not the way I thought it was... Sorry about this. It seems I'm not able to track down what is the exact limit for the problem to show up. It's probably something like a 600x400 window. I've added traces, all arround and I've also tried to remove the VID_DOUBLE_LINEBUFFER_FOR_WIDE_SRC flag and it has no effect. Amazingly enough, I have 1 video that doesn't show the problem, whatever the size of the output window (maybe RGB not showing the problem while YUV does ? I don't know if that makes any sense). All other videos I have show the problem. Any clue where I should look next ? Cheers, -- Olivier Fourdan [EMAIL PROTECTED] http://www.xfce.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
