Re: Alan H's new linear allocator and Neomagic Xv
On Wed, 29 Oct 2003, Alan Hourihane 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. I have a chipset, if someone can can give me pointers to what to look at. I wont be able to look for a week or two, since the hard disk on the laptop has died, and needs to be replaced. -- Andrew C Aitchison ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 08:09:05AM +, Andrew C Aitchison wrote:
On Wed, 29 Oct 2003, Alan Hourihane 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.
I have a chipset, if someone can can give me pointers to what to look at.
I wont be able to look for a week or two, since the hard disk on the
laptop has died, and needs to be replaced.
Well, if someone else has a chip, or wants to update and test other
drivers (but be careful with DRI enabled drivers as it needs more work
in the driver). Here's a patch to the neomagic that should work, and
could be used as a template for the other drivers.
That's all. Most Xv (if not all) use linear allocation already and will
take advantage of it straight away without any furthur modifications.
Alan.
Index: neo_driver.c
===
RCS file: /X11R6/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c,v
retrieving revision 1.71
diff -u -r1.71 neo_driver.c
--- neo_driver.c24 Sep 2003 03:16:55 - 1.71
+++ neo_driver.c30 Oct 2003 10:05:04 -
@@ -1685,11 +1685,20 @@
AvailFBArea.y1 = 0;
AvailFBArea.x2 = pScrn-displayWidth;
AvailFBArea.y2 = lines;
- xf86InitFBManager(pScreen, AvailFBArea);
-
- xf86DrvMsg(pScrn-scrnIndex, X_INFO,
- Using %i scanlines of offscreen memory \n,
+ if (xf86InitFBManager(pScreen, AvailFBArea)) {
+ int cpp = pScrn-bitsPerPixel / 8;
+ int area = lines * pScrn-displayWidth;
+ int areaoffset = area * cpp;
+
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+ Using %i scanlines of offscreen memory for area's \n,
lines - pScrn-virtualY);
+
+ if ( xf86InitFBManagerLinear(pScreen, area, (nPtr-NeoFbMapSize -
area))) {
+ xf86DrvMsg(scrnIndex, X_INFO,
+ Using the rest of offscreen memory for linear
(offset=0x%x,size=%3.1fMB)\n, areaoffset, (float)(nPtr-NeoFbMapSize -
(areaoffset/(1024*1024;
+ }
+ }
}
/* Setup the acceleration primitives */
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Server regeneration no longer works
On Thu, 30 Oct 2003, [ISO-8859-1] Frank Gießler wrote: snip cvs rdiff -D 15 October 2003 -D 16 October 2003 Xserver/os gives: snip Thanks, it is indeed the same bug. I've marked the one in Bugzilla as fixed. Is there an easy way to figure out the dates for the diffs? Also, cvsweb.xfree86.org allows easy viewing of changes. That's how I found out. But one has to know which files to investigate, and if more than one file is involved it can be a real PITA. Or am I missing something? Search cvs-commits list archives, and/or use the cvsps tool to generate patchsets. You can find the latter with google. The documentation blows goats but the tool works awesome once you mess with it for hours and hours wasting time until you figure out the right magic. ;o) It's a godsend. -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 10:07:13AM +, Alan Hourihane wrote:
On Thu, Oct 30, 2003 at 08:09:05AM +, Andrew C Aitchison wrote:
On Wed, 29 Oct 2003, Alan Hourihane 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.
I have a chipset, if someone can can give me pointers to what to look at.
I wont be able to look for a week or two, since the hard disk on the
laptop has died, and needs to be replaced.
Well, if someone else has a chip, or wants to update and test other
drivers (but be careful with DRI enabled drivers as it needs more work
in the driver). Here's a patch to the neomagic that should work, and
could be used as a template for the other drivers.
That's all. Most Xv (if not all) use linear allocation already and will
take advantage of it straight away without any furthur modifications.
Actually,
Due to the neomagic driver having different use of NeoFbMapSize, here's
a new followup.
Alan.
Index: neo_driver.c
===
RCS file: /X11R6/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c,v
retrieving revision 1.71
diff -u -r1.71 neo_driver.c
--- neo_driver.c24 Sep 2003 03:16:55 - 1.71
+++ neo_driver.c30 Oct 2003 11:05:23 -
@@ -1685,11 +1685,21 @@
AvailFBArea.y1 = 0;
AvailFBArea.x2 = pScrn-displayWidth;
AvailFBArea.y2 = lines;
- xf86InitFBManager(pScreen, AvailFBArea);
-
- xf86DrvMsg(pScrn-scrnIndex, X_INFO,
- Using %i scanlines of offscreen memory \n,
+ if (xf86InitFBManager(pScreen, AvailFBArea)) {
+ int cpp = pScrn-bitsPerPixel / 8;
+ int area = lines * pScrn-displayWidth;
+ int areaoffset = area * cpp;
+ int totalmapsize = (pScrn-videoRam * 1024);
+
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+ Using %i scanlines of offscreen memory for area's \n,
lines - pScrn-virtualY);
+
+ if ( xf86InitFBManagerLinear(pScreen, area, (totalmapsize - area))) {
+ xf86DrvMsg(scrnIndex, X_INFO,
+ Using the rest of offscreen memory for linear
(offset=0x%x,size=%3.1fMB)\n, areaoffset, (float)(totalmapsize -
(areaoffset/(1024*1024;
+ }
+ }
}
/* Setup the acceleration primitives */
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 11:06:45AM +, Alan Hourihane wrote: On Thu, Oct 30, 2003 at 10:07:13AM +, Alan Hourihane wrote: On Thu, Oct 30, 2003 at 08:09:05AM +, Andrew C Aitchison wrote: On Wed, 29 Oct 2003, Alan Hourihane 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. I have a chipset, if someone can can give me pointers to what to look at. I wont be able to look for a week or two, since the hard disk on the laptop has died, and needs to be replaced. Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Actually, Due to the neomagic driver having different use of NeoFbMapSize, here's a new followup. Sorry, another followup for Andrew really. The hardware cursor code should be made to use the linear allocator too, and the overlay_mem code could be removed. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
Andrew, I've just committed a patch to the trident driver to enable it. Best use that as the basis for the neomagic work. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 -Billy ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree CVS Blocker Bugreport
On Thu, 2003-10-30 at 03:14, Ali Akcaagac wrote: Please bear with me abusing the ML for reporting this bug. But It's quite seldom that I report anything to XFree thus I didn't wanted to open yet another bugzilla account for this. I would like to ask whether it is possible for you developers to track this issue down in the current XFree CVS HEAD which is a nagging bugger when using GTK+ 2.3.0 and leads applications to crash. The bug is inside XFree for quite some months now and is probably related to 'miscompute network buffer pointers' or something. I am no XFree or Xlib specialist so I am not in the position to track this down better (I am only a developer hacking some GTK/GNOME apps more or less). Thus I searched on the net and found two bugreports that leads to the same issue: http://pdx.freedesktop.org/pipermail/xlibs/2003-October/04.html http://bugzilla.gnome.org/show_bug.cgi?id=118436 http://bugzilla.xfree86.org/show_bug.cgi?id=839 Has the minimal 6 character patch. Regards, Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003 08:20:52 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: basically you are competing with the wm. you need to basically hack/modify/patch and work WITH the wm to do what you want. you cant do it on your own. now your solution will be wm specific. So it this means I have to use another way. :) Creating a undecorated invisble window which always stays on top and is only one pixel in width will be possible? This way I can align it the the border the user chooses and then I will get the events for sure. I suppose this should work independent of the WM, right? Do you by chance know how to create such a window as a GtkWidget? If not, no problem, I hope I can find some samples for this on the web. Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. -- 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: C+T 69030 driver on powerpc
so I correct myself. looks like its nothing to do with the kernel framebuffer driver. it mroe to do with the state the card gets left in after being half configured *phew*!! so thats makes life a bit easier - i just need to fix the card configuration! This should not happen. It can only happen when the Xserver has the ROM BIOS mapped. Judging from your log that shouldn't happen. Can you find out where it happens? You can hardcode a test for the relevant PCI config space register and PCI tag in the appropriate PciWrite() function and call a function you can breakpoint from gdb. There are three functions for this purpose: xf86Break1/2/3(). Debugged! The mangling occurs when it trys and fails to map the ROM BIOS (and of course my embedded board doesnt have a rom bios..). Mangling occurs in handlePciBIOS, i'm afraid i'm not knowledgable enough about how this code should work to explain why, tho. It seems that when xf86ReadDomainMemory fails and it tries to restore the base register with if (savebase) pciWriteLong(Tag, PCI_MAP_REG_START + (b_reg 2),(CARD32) savebase); (where b_reg=0, savebase=0xfa00) the card doesnt like this and resets BASE0! (i.e. the line 'BASE0 0xfa00 addr 0xfa00 MEM' disappears from scanpci -v) odd. Luckily i can just work around this using NoINT10 :) Onwards! Rob Taylor Senior Developerrobt at flyingpig dot com Flying Pig Systems http://www.flyingpig.com Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003, Gerhard W. Gruber wrote: Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. I believe that the RECORD extension is what people use for that sort of thing. xc/doc/hardcopy/Xext/record.PS.gz xc/doc/hardcopy/Xext/recordlib.PS.gz xc/doc/specs/Xext/record.ms xc/doc/specs/Xext/recordlib.ms Don't know whether it will help you at all. -- 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: Capturing events from the root window
On Thu, 2003-10-30 at 20:18, Dr Andrew C Aitchison wrote: On Thu, 30 Oct 2003, Gerhard W. Gruber wrote: Thanks for your explanation though. I wonder why such a thing never has been implemented. From what I saw brwosing the web I'm not the only one who could use this for some desktop tools. Also I wonder how event recorder will do their job under X? Xnee uses RECORD extension to do recording. Have a look at http://www.gnu.org/software/xnee/ Xnee replays as well, using the XTest extension. Or is there nos such application for X? Tools similar to WinRunner which capture all events and play them back later. Don't know anything about WinRunner! Anyway, xnee (as said) does record and replay. /hesa ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Capturing events from the root window
On Thu, 30 Oct 2003 19:18:31 + (GMT), Dr Andrew C Aitchison [EMAIL PROTECTED] wrote: I believe that the RECORD extension is what people use for that sort of Recording is not really what I need for my app, because I will only see the events and can not prevent them from getting through to other apps. :) -- 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 Fri, 31 Oct 2003 08:51:07 +1100, Carsten Haitzler (The Rasterman) [EMAIL PROTECTED] wrote: you willonly then get events when the mouse passes over your thin window. That's no problem as long as my window stays on top. not as a widget - no. you'll have to jump down to gdk. i'm not sure if gdk supports this though. you'll want an inputonly window thats a toplevel window (immediate child of root) thats override-redirect. you'll need to also monitor I managed to create an invisible window which is only one pixel in widht and has the same height as the screen (hardcoded for now, how can I query the current resolution?). The only problem, I still have is, to make the window stay on top of all others in order to always receive input events when the user moves the mouse to the right border (or where he configured it). Is it possible to create a window that always stays on top? Not only of it's own application, but of all application windows. If not, is it possible to get an event when my window is obscured or lowered because another window has been raised over it? Actually getting the inof when it is obscored would be enough because it only needs to stay accessible all the time and for this it doesn't have to be the top window. And can I raise a window above all others? I browsed the web for this, but it seems that is also not possible. Everytime I think of a new way how to achieve what I need it seems to be blocked by X. :( all client windows, where they move, go etc. and follow i'm still not even 100% sure what it is you want to actually do (in overall aim) You can take a look in the readme at http://sourceforge.net/projects/launchmenu, there I explain it. Its just a simple app that has been proven quite usefull to me over the years and I wrote this for myself because the original source is not portable and the author doesn't give away all the source anyway. If you don't want to download the package, it is of course in the CVS as well. there's a whole extension devoted to recording events - the xrecord extension - but i know very little about it. :) No prob. It wouldn't do what I need anyway. -- 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: XFree86 specific patch to freetype-config.in
Matthieu Herrb wrote (in a message from Tuesday 28)
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.
Here's the patch I intend to commit. I didn't want to use
EXTRA_LOAD_FLAGS directly, as its semantics is not clearly defined.
I've used 'hardcode_libdir_flag_spec' for consistancy with
autoconf/libtool.
Someone also mentionned possible issues on mixed 32/64 bits platforms
where a separate directory may be used for 64 bit versions of the
libraries; more work is needed in this case in other areas too...
Matthieu
Index: xc/config/cf/Imake.tmpl
===
RCS file: /cvs/xf86/xc/config/cf/Imake.tmpl,v
retrieving revision 3.151
diff -u -r3.151 Imake.tmpl
--- xc/config/cf/Imake.tmpl 29 Oct 2003 05:51:37 - 3.151
+++ xc/config/cf/Imake.tmpl 30 Oct 2003 22:52:38 -
@@ -991,6 +991,9 @@
#ifndef DefaultCplusplusOptions
#define DefaultCplusplusOptions /* floating point, etc. */
#endif
+#ifndef HardCodeLibdirFlag
+#define HardCodeLibdirFlag /**/
+#endif
#ifndef NoRConst
#define NoRConst NO /* YES if const for structs of funcs is bad */
#endif
Index: xc/config/cf/OpenBSDLib.rules
===
RCS file: /cvs/xf86/xc/config/cf/OpenBSDLib.rules,v
retrieving revision 1.9
diff -u -r1.9 OpenBSDLib.rules
--- xc/config/cf/OpenBSDLib.rules 11 Oct 2003 09:40:09 - 1.9
+++ xc/config/cf/OpenBSDLib.rules 30 Oct 2003 22:52:38 -
@@ -53,7 +53,10 @@
#define ExtraLoadFlags -Wl,-rpath,$(USRLIBDIRPATH) -Wl,-rpath-link,$(BUILDLIBDIR)
#endif
#endif
+#ifndef HardCodeLibdirFlag
+#define HardCodeLibdirFlag -Wl,-rpath,$(USRLIBDIRPATH)
#endif
+#endif /* UseElfFormat */
/*
* InstallSharedLibrary - generate rules to install the shared library.
Index: xc/config/cf/bsdLib.rules
===
RCS file: /cvs/xf86/xc/config/cf/bsdLib.rules,v
retrieving revision 3.24
diff -u -r3.24 bsdLib.rules
--- xc/config/cf/bsdLib.rules 18 Oct 2003 17:21:41 - 3.24
+++ xc/config/cf/bsdLib.rules 30 Oct 2003 22:52:39 -
@@ -201,6 +201,10 @@
#endif
#endif
+#ifndef HardCodeLibdirFlag
+#define HardCodeLibdirFlag -Wl,-rpath,$(USRLIBDIRPATH)
+#endif
+
#if !defined(ShlibGlobalsFlags)
#define ShlibGlobalsFlags -Wl,-Bsymbolic
#endif
Index: xc/config/cf/lnxLib.rules
===
RCS file: /cvs/xf86/xc/config/cf/lnxLib.rules,v
retrieving revision 3.51
diff -u -r3.51 lnxLib.rules
--- xc/config/cf/lnxLib.rules 25 Oct 2003 01:21:25 - 3.51
+++ xc/config/cf/lnxLib.rules 30 Oct 2003 22:52:39 -
@@ -85,7 +85,9 @@
# define ExtraLoadFlags -Wl,-rpath,$(USRLIBDIRPATH)
# endif
# endif
-
+# ifndef HardCodeLibdirFlag
+# define HardCodeLibdirFlag -Wl,-rpath,$(USRLIBDIRPATH)
+# endif
# if !defined(ShlibGlobalsFlags)
# define ShlibGlobalsFlags -Wl,-Bsymbolic
# endif
Index: xc/extras/fontconfig/fontconfig-config.in
===
RCS file: /cvs/xf86/xc/extras/fontconfig/fontconfig-config.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fontconfig-config.in
--- xc/extras/fontconfig/fontconfig-config.in 4 Jun 2003 02:56:24 - 1.1.1.1
+++ xc/extras/fontconfig/fontconfig-config.in 30 Oct 2003 22:52:40 -
@@ -3,6 +3,7 @@
prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
[EMAIL PROTECTED]@
includedir=@includedir@
version=@PACKAGE_VERSION@
@@ -85,7 +86,7 @@
if test $echo_libs = yes ; then
libs=-lfontconfig
if test ${libdir} != /usr/lib ; then
- echo -L${libdir} $libs
+ echo ${hardcode_libdir_flag_spec} -L${libdir} $libs
else
echo $libs
fi
Index: xc/extras/fontconfig/fontconfig.pc.in
===
RCS file: /cvs/xf86/xc/extras/fontconfig/fontconfig.pc.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fontconfig.pc.in
--- xc/extras/fontconfig/fontconfig.pc.in 4 Jun 2003 02:56:24 - 1.1.1.1
+++ xc/extras/fontconfig/fontconfig.pc.in 30 Oct 2003 22:52:40 -
@@ -1,10 +1,11 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
Name: Fontconfig
Description: Font configuration and customization library
Version: @PACKAGE_VERSION@
-Libs: -L${libdir} -lfontconfig
+Libs: ${hardcode_libdir_flag_spec} -L${libdir} -lfontconfig
Cflags: -I${includedir}
Index:
Re: Capturing events from the root window
On Thu, 30 Oct 2003 23:07:37 +0100 "Gerhard W. Gruber" [EMAIL PROTECTED] (Bbabbled: (B (B On Fri, 31 Oct 2003 08:51:07 +1100, Carsten Haitzler (The Rasterman) (B [EMAIL PROTECTED] wrote: (B (B you willonly then get events when the mouse passes over your thin window. (B (B That's no problem as long as my window stays on top. (B (Baaah thats a problem. (B (B not as a widget - no. you'll have to jump down to gdk. i'm not sure if gdk (B supports this though. you'll want an inputonly window thats a toplevel window (B (immediate child of root) thats override-redirect. you'll need to also (B monitor (B (B I managed to create an invisible window which is only one pixel in widht and (B has the same height as the screen (hardcoded for now, how can I query the (B current resolution?). The only problem, I still have is, to make the window (B stay on top of all others in order to always receive input events when the (B user moves the mouse to the right border (or where he configured it). (B (Bnot as easy as it sounds too :) (B (B Is it possible to create a window that always stays on top? Not only of it's (B own application, but of all application windows. (B (Bno. the wm - or any app can go raising windows above yours... you cant clock (Bwindows in place to be on top as such. (ok we can argue of some nasty hacks and (Bmethods if you are the wm... but thats a world on its own.) (B (B If not, is it possible to get an event when my window is obscured or lowered (B because another window has been raised over it? Actually getting the inof when (B it is obscored would be enough because it only needs to stay accessible all (B the time and for this it doesn't have to be the top window. And can I raise a (B window above all others? I browsed the web for this, but it seems that is also (B not possible. Everytime I think of a new way how to achieve what I need it (B seems to be blocked by X. :( (B (Bok. for a normal window yes its possible to get events to know if you got (Bobscured. they are called visibilitynotify events. BUT i am actually not sure if (Bthey will be received by inputonly windows. but thats the path you want to go. (Byou could find if a window has been raised/lowered etc. by monitoring (Bcreatnotifies on root, then on every windows created monitor structurenotifies (Bthen look for configurenotify events and check the stacking sections (above, (Bwindow, event). again - i dont know how well gdk(gtk) supports this part of x so (Byou may have to dump into xlib. (B (B (B all client windows, where they move, go etc. and follow i'm still not (B even 100% sure what it is you want to actually do (in overall aim) (B (B You can take a look in the readme at (B http://sourceforge.net/projects/launchmenu, there I explain it. Its just a (B simple app that has been proven quite usefull to me over the years and I wrote (B this for myself because the original source is not portable and the author (B doesn't give away all the source anyway. (B If you don't want to download the package, it is of course in the CVS as well. (B (Bhmm how is it meant to work? mouse goes to left or right side of window, (Blauncher buttons pop up and u click one to run something? (B (B there's a whole extension devoted to recording events - the xrecord extension (B - but i know very little about it. :) (B (B No prob. It wouldn't do what I need anyway. (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: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
I'll take a look at fixing this in the radeon driver. What needs to be done to play nice with the DRI? Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. 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: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
I've actually already done it, but I'll probably leave it till after XFree86 4.4.0. Once 4.4.0 is out, I'll merge that into the DRI CVS and create a branch for this work I've been doing on the radeon with regard to dynamic allocation the DRI. Alan. On Thu, Oct 30, 2003 at 07:36:42AM -0800, Alex Deucher wrote: I'll take a look at fixing this in the radeon driver. What needs to be done to play nice with the DRI? Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. 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 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
Alan Hourihane ([EMAIL PROTECTED]): I've actually already done it, but I'll probably leave it till after XFree86 4.4.0. Regarding bug 830, does this mean my users can expect to sometimes hit these situations where XVIDEO apps can't run until they shut down a large application like their web browser? Don't take this the wrong way, I don't mind, I just want to understand the situation so I can design appropriate error messages. -Billy Once 4.4.0 is out, I'll merge that into the DRI CVS and create a branch for this work I've been doing on the radeon with regard to dynamic allocation the DRI. Alan. On Thu, Oct 30, 2003 at 07:36:42AM -0800, Alex Deucher wrote: I'll take a look at fixing this in the radeon driver. What needs to be done to play nice with the DRI? Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. 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 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 10:59:41AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): I've actually already done it, but I'll probably leave it till after XFree86 4.4.0. Regarding bug 830, does this mean my users can expect to sometimes hit these situations where XVIDEO apps can't run until they shut down a large application like their web browser? Don't take this the wrong way, I don't mind, I just want to understand the situation so I can design appropriate error messages. Low memory situations should only happen when a 3D application is also running. I'm not sure why you'd be hitting it when it's not. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
