Xfbdev problem
Hi all, I m trying to run Xfbdev(tinyX) on s3c2410... but when i try to execute it, it says _ # startx hostname: (none): Unknown host mcookie: No such file or directory xauth: timeout in locking authority file //.Xauthority xauth: timeout in locking authority file //.Xauthority xauth: timeout in locking authority file //.Xauthority xauth: timeout in locking authority file //.Xauthority _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/(none):0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 Fatal server error: Failed to establish all listening sockets giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. xauth: timeout in locking authority file //.Xauthority command: No such file or directory # _ Any kind of help would be appreciated. Thanx n Regards, Jassi
Re: glxgears lock up MDK9.2 with radeon 9200
On Wed, 2003-10-29 at 01:23, Emmanuel Allaud wrote: Hi all, I just installed a MDK 9.2, and as the agpgart module seems OK with my nForce2 chipset, I also loaded DRI. All logs are OK, the dri modules load correctly; but if I launch glxgears it locks up solid (hard reset only to get rid of it). I use the radeon driver of MDK9.2 for my radeon 9200 (from chaintech IIRC). Please try a recent r200 snapshot from http://dri.sourceforge.net/snapshots/ and post to the dri-devel list or file a bug at http://bugs.xfree86.org if the problem persists. -- Earthling Michel Dnzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Alan H's new linear allocator and Neomagic Xv
As I recall we had problems with allocating additional memory for Xv on neomagic chips (hence the overly_mem option). As I recall there was an issue with allocating memory beyond the limits of the blitter, similar to the problems with Xv on via (bug 525). Could this issue be resolved with Alan H's new linear allocator? Just curious. Alex __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 08:20:00 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: again - see my other reply. you've found a can of worms that basically x doesn't do. ou COULD do this with mouse button presses (XGrabButton) and the dot he XAllowEvent thing... but not just the mouse moving in general. you'd hit a I don't need the mouse movements. I just need the buttons. I read something today about XAllowEvents and I had the impression that this could do what I wanted, but I can't put my finger on it, because I don't know enough about Xlib. limitation of x. you'd HAVE to extend X itself with an extension to do what you are after (unless there is an extension of this i don't know of somewhere. i know xtest wont do it for sure...) Well, xtest is only a small program to test how I can achieve this. I never claimed it would do this and it also isn't finished. It just that, a testprogram so that I don't have to deal with a fullblown application and GTK and wxWindows also. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 08:17:30 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: this has issues all of its own. first. other peoples windows need to get the correct event at the correct location and time - which now won't be right as windows may have been destroyed, created, shown and hidden, moved and resized, I don't see a problem with this. 1) Why is the timing so critical? The delay should be very small because I just check the event type and would pass it right back on. And 2) even if the timing is wrong, what's the deal? I capture all the events and pass it back (If I manage to find out how this can be done), so the timing is delayed for a, more or less, constant factor. It's not as if my application is real time ciritical, its just a small desktop helper tool. X always has to deal with events not sent to the proper window because of destruction or other things. to re-construct the event to send. your chances of getting this correct are getting slimmer by the second, ESPECIALLY since X is an synchronous environment, I sure don't want to write something like a windowmanager just to support my app. :) also since you have the mouse grabbed to your window (unless you use a big input-only window on top of everything... another can of worms on its own), this I don't have a window and I don't want a proxy window. I would like to use the desktop root window. i can probably find more holes to poke in it all - but suffice to say however you look at it you'll NEVER get it right. your only choice to find out what the mouse is doing outside windows you're listening for events on is to poll. you cannot intercept and optionally not send an event. Suppose I would poll for it then there would still be two questions: 1) How can I poll for this? 2) What do I do if a find that my criteria is met. The requirement is that in that case I should suppress the original message and do my own processing. How can I achieve this? It wouldn't do to scan for Mousebuttonpress and then display the menu and the original app also displays it's context menu. This would be ugly and confusing for the user. this is actually one of x's downfalls which should be fixed. the ability to monitor events globally/in general without having to specifically select on them on target windows. then add the ability to allow/disallow them to go to the next guy listening (first in first served ala the wm?). Yes. That's what the MS Windows Hook mechanism do. There are also limitations, but I managed to work around this to get the tool working mostly as I want it to, though it can use some improvements, but for now I'm content until I can get the linux version working as well. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 21:13:33 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Wed, 29 Oct 2003 08:20:00 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B again - see my other reply. you've found a can of worms that basically x (B doesn't do. ou COULD do this with mouse button presses (XGrabButton) and the (B dot he XAllowEvent thing... but not just the mouse moving in general. you'd (B hit a (B (B I don't need the mouse movements. I just need the buttons. I read something (B today about XAllowEvents and I had the impression that this could do what I (B wanted, but I can't put my finger on it, because I don't know enough about (B Xlib. (B (Bactually ignore my XGrabButton thing. i forgot that by trying this you'll (Bdisable any wm being able to do click to focus :( you basically are stuck. x (Bcan't do what you want. but just so you know, XAllowEvents is used in (Bcombination with XGrabButton (or XGrabKey). When you passively grab a button or (Bkey on a window, when that button or key (+ modifiers) is pressed, the client (Bthat grabbed gets the event, not the destination window. you cna now process, do (Bsomething (ie for the wm this would be used to do click to focus - ie focus the (Bwindow if it isnt focused). then you can use XAllowEvents to have that event (B"fall through" to its originally intended destination. caveta. if you read any (Bother events from the queue before calling x allowevent you can no longer allow (Bthe event through (imho a real let-down in xlib). BUt again - this is not useful (Bto you as the wm will have grabbed on window frames to do click to focus and (Bthus ancestors of root will have grabs and thus your XGrabButton will fail to (Bactually grab anything. (B (B limitation of x. you'd HAVE to extend X itself with an extension to do what (B you are after (unless there is an extension of this i don't know of (B somewhere. i know xtest wont do it for sure...) (B (B Well, xtest is only a small program to test how I can achieve this. I never (B claimed it would do this and it also isn't finished. It just that, a (B testprogram so that I don't have to deal with a fullblown application and GTK (B and wxWindows also. (B (Bi meant XTest extension (you can fake events with this - with limitations). (B (B (B -- (B Gerhard Gruber (B (B Klar, einleuchtend und falsch. (Henry Louis Mencken) (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am" (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Wed, 29 Oct 2003 21:21:16 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Wed, 29 Oct 2003 08:17:30 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B this has issues all of its own. first. other peoples windows need to get the (B correct event at the correct location and time - which now won't be right as (B windows may have been destroyed, created, shown and hidden, moved and (B resized, (B (B I don't see a problem with this. 1) Why is the timing so critical? The delay (B should be very small because I just check the event type and would pass it (B (Bx is asynchronous. let me take an extreme example. i get an event - now i wait 1 (Bsecond then send something along. in that 1 second the window the event happened (Bin could have been closed, moves, destroyed, resized etc. this then changes all (Bthe conditions we had. (B (B right back on. And 2) even if the timing is wrong, what's the deal? I capture (B all the events and pass it back (If I manage to find out how this can be (B done), so the timing is delayed for a, more or less, constant factor. It's not (B as if my application is real time ciritical, its just a small desktop helper (B tool. X always has to deal with events not sent to the proper window because (B of destruction or other things. (B (Bthe timing is important in 2 ways. the way above as i mentioned AND 2. that you (Bset the time member of the event correctly because many apps use that for (Binterpreting double clicks, "quick click" as opposed to "click and drag" for (Bmenu popping up etc. (B (B to re-construct the event to send. your chances of getting this correct are (B getting slimmer by the second, ESPECIALLY since X is an synchronous (B environment, (B (B I sure don't want to write something like a windowmanager just to support my (B app. :) (B (BBUT what you are doing is the domain of window managers. its low level x (Bfiddling and almost everything you do comes with a caveat, exception and (Bproblem. you cant control your environment as well as an app can control things (Bwithin their own windows. (B (B also since you have the mouse grabbed to your window (unless you use a big (B input-only window on top of everything... another can of worms on its own), (B this (B (B I don't have a window and I don't want a proxy window. I would like to use the (B desktop root window. (B (BXGrabButton then - BUT as i said in my other e-mail. this wont work as (Bclick-to-focus will get broken (for starters) not to mention alt+left click (Bdragging etc. (if your wm does it). you're playing games at competing with the (Bwm here - and since the wm is likely run first and going to be pretty stubborn (Babout "winning" you're fighting an uphill battle where the only result will be (Bbroken behavior to the user, and neither you nor the wm will work properly. (B (B i can probably find more holes to poke in it all - but suffice to say however (B you look at it you'll NEVER get it right. your only choice to find out what (B the mouse is doing outside windows you're listening for events on is to poll. (B you cannot intercept and optionally not send an event. (B (B Suppose I would poll for it then there would still be two questions: (B (B 1) How can I poll for this? (B (BXQyeryPointer (B (B 2) What do I do if a find that my criteria is met. The requirement is that in (B that case I should suppress the original message and do my own processing. How (B can I achieve this? (B (Byou cant suppress the original event. now without XGrabButton/XGrabKey - and as (Bi said before - that wont work. (B (B It wouldn't do to scan for Mousebuttonpress and then display the menu and the (B original app also displays it's context menu. This would be ugly and confusing (B for the user. (B (Bbasically you are competing with the wm. you need to basically hack/modify/patch (Band work WITH the wm to do what you want. you cant do it on your own. now your (Bsolution will be wm specific. (B (B this is actually one of x's downfalls which should be fixed. the ability to (B "monitor" events globally/in general without having to specifically select on (B them on target windows. then add the ability to allow/disallow them to go to (B the next guy listening (first in first served ala the wm?). (B (B Yes. That's what the MS Windows Hook mechanism do. There are also limitations, (B but I managed to work around this to get the tool working mostly as I want it (B to, though it can use some improvements, but for now I'm content until I can (B get the linux version working as well. (B (B -- (B Gerhard Gruber (B (B Klar, einleuchtend und falsch. (Henry Louis Mencken) (B (B ___ (B Devel mailing list (B [EMAIL PROTECTED] (B http://XFree86.Org/mailman/listinfo/devel (B (B (B-- (B--- Codito, ergo sum - "I code, therefore I am"
Re: Alan H's new linear allocator and Neomagic Xv
On Wed, Oct 29, 2003 at 12:26:45PM -0800, Alex Deucher wrote: As I recall we had problems with allocating additional memory for Xv on neomagic chips (hence the overly_mem option). As I recall there was an issue with allocating memory beyond the limits of the blitter, similar to the problems with Xv on via (bug 525). Could this issue be resolved with Alan H's new linear allocator? From looking at the driver. Yes it can. But I don't have a neomagic chipset to test. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glxgears lock up MDK9.2 with radeon 9200
Le 29.10.2003 18:36:27, Michel Dnzer a crit: On Wed, 2003-10-29 at 01:23, Emmanuel Allaud wrote: Hi all, I just installed a MDK 9.2, and as the agpgart module seems OK with my nForce2 chipset, I also loaded DRI. All logs are OK, the dri modules load correctly; but if I launch glxgears it locks up solid (hard reset only to get rid of it). I use the radeon driver of MDK9.2 for my radeon 9200 (from chaintech IIRC). Please try a recent r200 snapshot from http://dri.sourceforge.net/snapshots/ and post to the dri-devel list or file a bug at http://bugs.xfree86.org if the problem persists. OK thanks, will do that ASAP. Do you think I can just usethe snapshot against XF4.3.0 from MDK9.2 (re compiling DRI stuff is OK but XFree itself would be a bit harder ;-) Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Alan H's new linear allocator and Neomagic Xv
unfortunately neither do I, or I'd give it a shot. Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Wed, Oct 29, 2003 at 12:26:45PM -0800, Alex Deucher wrote: As I recall we had problems with allocating additional memory for Xv on neomagic chips (hence the overly_mem option). As I recall there was an issue with allocating memory beyond the limits of the blitter, similar to the problems with Xv on via (bug 525). Could this issue be resolved with Alan H's new linear allocator? From looking at the driver. Yes it can. But I don't have a neomagic chipset to test. Alan. __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glxgears lock up MDK9.2 with radeon 9200
make sure you also get the XFree86 package from the extras directory or you will get an error because your server is too old. Alex --- manu [EMAIL PROTECTED] wrote: Le 29.10.2003 18:36:27, Michel Dänzer a écrit : On Wed, 2003-10-29 at 01:23, Emmanuel Allaud wrote: Hi all, I just installed a MDK 9.2, and as the agpgart module seems OK with my nForce2 chipset, I also loaded DRI. All logs are OK, the dri modules load correctly; but if I launch glxgears it locks up solid (hard reset only to get rid of it). I use the radeon driver of MDK9.2 for my radeon 9200 (from chaintech IIRC). Please try a recent r200 snapshot from http://dri.sourceforge.net/snapshots/ and post to the dri-devel list or file a bug at http://bugs.xfree86.org if the problem persists. OK thanks, will do that ASAP. Do you think I can just usethe snapshot against XF4.3.0 from MDK9.2 (re compiling DRI stuff is OK but XFree itself would be a bit harder ;-) Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Server regeneration no longer works
On Tue, Oct 28, 2003 at 12:48:36PM +0100, Frank Gießler wrote:
David Dawes wrote:
On Wed, Oct 15, 2003 at 04:17:35PM -0400, David Dawes wrote:
On Wed, Oct 15, 2003 at 12:53:32PM -0400, Mark Vojkovich wrote:
Start the server with no clients and access control disabled
XFree86 -ac. Run a client and kill it, or run a client that
terminates itself (like xset) and the server segfaults on the
server regeneration. I'm having a hard time getting a back trace.
It looks like the stack is trashed pretty badly. This appears
to be a recent regression.
It looks like a malloc/free bug -- maybe a double free somewhere. I
see it crashing in free(), called from CMapUnwrapScreen(). If I add
some debugging ErrorF's the caller of the crashing free() moves. I'll
try a build on FreeBSD and enable some of its malloc debugging flags.
That located the problem nicely, aborting at the actual double-free.
The screen saver timers get freed in TimerInit() for each generation.
However, the timer pointers kept by the screen saver code weren't being
cleared for each generation, so the old values kept being used and added
back to the timers list. Then they'd get freed again in TimerInit() at
the second regeneration. Not to mention that freed memory was still
being used. I'm going to commit a fix that clears the Screensaver and
DPMS timers at each regeneration.
David
Is this fix available as a single patch? I would like to check whether this also
fixes
Bugzilla's #776.
cvs rdiff -D 15 October 2003 -D 16 October 2003 Xserver/os
gives:
Index: xc/programs/Xserver/os/WaitFor.c
diff -u xc/programs/Xserver/os/WaitFor.c:3.41 xc/programs/Xserver/os/WaitFor.c:3.42
--- xc/programs/Xserver/os/WaitFor.c:3.41 Thu Sep 25 09:26:27 2003
+++ xc/programs/Xserver/os/WaitFor.cWed Oct 15 21:33:35 2003
@@ -1,4 +1,4 @@
-/* $XFree86: xc/programs/Xserver/os/WaitFor.c,v 3.41 2003/09/25 13:26:27 pascal Exp $
*/
+/* $XFree86: xc/programs/Xserver/os/WaitFor.c,v 3.42 2003/10/16 01:33:35 dawes Exp $
*/
/***
Copyright 1987, 1998 The Open Group
@@ -112,7 +112,7 @@
};
static void DoTimer(OsTimerPtr timer, CARD32 now, OsTimerPtr *prev);
-static OsTimerPtr timers;
+static OsTimerPtr timers = NULL;
/*
* WaitForSomething:
@@ -568,10 +568,15 @@
}
static OsTimerPtr ScreenSaverTimer = NULL;
+static int ScreenSaverGeneration = -1;
void
SetScreenSaverTimer(void)
{
+if (ScreenSaverGeneration != serverGeneration) {
+ ScreenSaverTimer = NULL;
+ ScreenSaverGeneration = serverGeneration;
+}
if (ScreenSaverTime 0) {
ScreenSaverTimer = TimerSet(ScreenSaverTimer, 0, ScreenSaverTime,
ScreenSaverTimeoutExpire, NULL);
@@ -586,6 +591,7 @@
static OsTimerPtr DPMSStandbyTimer = NULL;
static OsTimerPtr DPMSSuspendTimer = NULL;
static OsTimerPtr DPMSOffTimer = NULL;
+static int DPMSGeneration = -1;
static CARD32
DPMSStandbyTimerExpire(OsTimerPtr timer,CARD32 now,pointer arg)
@@ -635,12 +641,19 @@
if (!DPMSEnabled)
return;
+if (DPMSGeneration != serverGeneration) {
+ DPMSStandbyTimer = NULL;
+ DPMSSuspendTimer = NULL;
+ DPMSOffTimer = NULL;
+ DPMSGeneration = serverGeneration;
+}
+
if (DPMSStandbyTime 0) {
DPMSStandbyTimer = TimerSet(DPMSStandbyTimer, 0, DPMSStandbyTime,
DPMSStandbyTimerExpire, NULL);
}
if (DPMSSuspendTime 0) {
-DPMSStandbyTimer = TimerSet(DPMSSuspendTimer, 0, DPMSSuspendTime,
+DPMSSuspendTimer = TimerSet(DPMSSuspendTimer, 0, DPMSSuspendTime,
DPMSSuspendTimerExpire, NULL);
}
if (DPMSOffTime 0) {
Also, cvsweb.xfree86.org allows easy viewing of changes.
A better approach is to explicitly free the timers at the end of each
generation. I committed that last night.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 specific patch to freetype-config.in
On Tue, Oct 28, 2003 at 08:13:42AM +0100, Matthieu Herrb wrote: Torrey Lyons wrote (in a message from Monday 27) The following revision to xc/extras/freetype2/builds/unix/freetype-config.in is XFree86 specific and not in the Freetype tree: revision 1.2 date: 2003/05/05 16:12:27; author: dawes; state: Exp; lines: +29 -15 159. Make freetype-config more useful on NetBSD (#5693, Thomas Klausner). cvs diff -r xf-4_3-branch -r 1.2 freetype-config.in Index: freetype-config.in === RCS file: /home/x-cvs/xc/extras/freetype2/builds/unix/freetype-config.in,v retrieving revision 1.1.1.4 retrieving revision 1.2 diff -u -d -b -w -r1.1.1.4 -r1.2 --- freetype-config.in 15 Feb 2002 00:33:20 - 1.1.1.4 +++ freetype-config.in 5 May 2003 16:12:27 - 1.2 @@ -90,7 +90,7 @@ if test $echo_libs = yes ; then libs=-lfreetype if test @libdir@ != /usr/lib ; then - echo [EMAIL PROTECTED]@ $libs + echo -Wl,[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ $libs else echo $libs fi Unfortunately, -R is not a recognized option to ld on Darwin and perhaps other platforms as well. This should be conditionalized in some way. My configure-foo is fairly weak, but it appears that the hardcode_libdir_flag_spec is the configure option that should be used here, rather then a hardwired ELF loader specific option. There's also bugzilla #832 that requests that the same is done for the other xxx-config and xxx.pc files shipped by XFree86. I'm going to handle it. Imake gets it right for the platforms we support, so extracting the info from there would minimise duplication. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glxgears lock up MDK9.2 with radeon 9200
Le 30.10.2003 00:10:00, Alex Deucher a écrit : make sure you also get the XFree86 package from the extras directory or you will get an error because your server is too old. Which extras directory? The one on the dri website? BTW : I understand that I must have the kernel sources, but I do not need to compile it actually? But I now think I need the whole source for XFree, don't I? Thanks Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glxgears lock up MDK9.2 with radeon 9200
Le 29.10.2003 17:41:38, manu a écrit : Le 30.10.2003 00:10:00, Alex Deucher a écrit : make sure you also get the XFree86 package from the extras directory or you will get an error because your server is too old. Which extras directory? The one on the dri website? BTW : I understand that I must have the kernel sources, but I do not need to compile it actually? But I now think I need the whole source for XFree, don't I? Hmm, just figured out that these are binaries... sorry for the stupid questions then ;-) Bye Manu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XFree86 4.4.0 status update
I'm expecting to tag the first pre-4.4 feature-complete snapshot (4.3.99.15) on 1 November 2003. It will be available from the development snapshots page http://www.xfree86.org/develsnaps/ at that time. The release is on track for a code freeze on 28 November 2003 and release in mid December 2003. http://www.xfree86.org/releaseplans.html David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
