[Xpert]Re: Status of Radeon support under XFree86
Cheers all, It's been quite some time since last post, but with school and all I felt I really needed to give this a proper shot when I had time for it. I still have gotten nowhere. I tried installing the binary distribution of the radeon dri module, as found on the dri-sf page, but that gave me another signal 11. With no luck getting this to run I just reinstalled the 4.2.0 binaries. I'm really trying to avoid having to compile XF86 myself, since I've heard it's not the most fun thing to do on a Saturday nite. From: Johannes Rath <[EMAIL PROTECTED]> Kacper, your board has to be 'build by ATI', for the firegl drivers to work. You are right, it isn't. Damn, if I had known back when I was buying it that this was a consideration.. From: Alexander Stohr <[EMAIL PROTECTED]> But ATI Radeon VE (similar to ATI Radeon 7000)=20 is based on a chip of a previous Radeon chip family. This design is _not_ in the scope of the ATI FireGL drivers. I am not aware of any report which states the opposite. I stand corrected. I do belive I meant the LE - or did I? All I can say is my experience is limited to my own QL. From: Michel =?ISO-8859-1?Q?D=E4nzer?= <[EMAIL PROTECTED]> > super-slow! What gives? I did have trouble loading glx earlier, but I > traced this problem to my enabling of the radeon framebuffer device in > the kernel. Huh? Must have been something else. No, I'm pretty sure that's it. I tried different versions of XF86 (admittedly, never cvs), but glx would not load. Recall a post Sep 30th where I was fretting about the fact, upon which I got a reply saying my libglx.so was out of date (Aitchison & Bruno). This might have been true at the time, but after reinstalling XF86 things were still looking glum, until it occured to me that it might be the fbdev. Mind you, I had similar problems with an nvidia card about a year ago. I disabled the radeon fbdev, and the glx loads. > Now glx loads, but performance is still crap. 3D acceleration is only supported for the 8500 in DRI CVS yet. As you're running Debian, http://dri.sourceforge.net/snapshots/README.Debian should be interesting to you. It doesn't work. I tried the debian-packaged snapshots and the x-server refuses to load, giving a signal 11. When I try regylar sid xf packages (4.2.1-3) I immediately need to do a hard reset. Only thing that works for me are the binaries. > * Video/dvd playback with mplayer and xine is good, but only with This should be fixed in current XFree86 and DRI CVS. That seems to be normal when trying to run dualhead with GATOS drivers. Are you saying the GATOS driver does not work with the dual output of the Radeon? The people on the gatos-devel list didn't seem to be able to confirm this. Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer Hardly on topic, but I wonder, since you are a Debian/powerpc developer: what are my chances at getting a pc radeon card to work in a apple macintosh? What about a GeForce 3 Ti? (I've looked into the matter and it seems the mac firmware does not exist) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
> "David" == David Dawes <[EMAIL PROTECTED]> writes:
David> Unless the old Type1 backend can unreservedly be replaced by
David> the new FreeType2 backend, then it should be disabled, and
David> maybe even a "fake" type1 font module created for the modular
David> build so that existing configurations don't break. If there
David> are still reasons for wanting the old backend, then it needs to
David> be configurable, at least at build-time.
I beleive the old type1 backend is still required for type1 cid fonts.
It would be useful to have an easy way of compiling it w/ the moral
equivilent of:
--- t1funcs.c.~1~ Mon Feb 18 15:51:57 2002
+++ t1funcs.c Tue Oct 22 00:57:09 2002
@@ -1434,16 +1434,20 @@
FontRendererRec CIDRendererInfo[] = {
{ ".cid", 4, NULL, CIDOpenScalable,
+NULL, CIDGetInfoScalable, 0, CAPABILITIES },
+ { ".CID", 4, NULL, CIDOpenScalable,
NULL, CIDGetInfoScalable, 0, CAPABILITIES }
};
#endif
-#ifdef BUILDCID
+#ifndef BUILD_ONLY_CID
+# ifdef BUILDCID
FontRendererRec Type1RendererInfo[] = {
-#else
+# else
static FontRendererRec renderers[] = {
-#endif
+# endif
{ ".pfa", 4, NULL, Type1OpenScalable,
NULL, Type1GetInfoScalable, 0, CAPABILITIES },
{ ".pfb", 4, NULL, Type1OpenScalable,
NULL, Type1GetInfoScalable, 0, CAPABILITIES }
};
+#endif
so that it will load .cid and .CID files but leave .pfa or .pfb for
the ft2 driver.
-JimC
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
On Mon, Oct 21, 2002 at 04:54:26PM -0400, David Dawes wrote: > On Fri, Oct 18, 2002 at 02:12:30PM -0700, Mark Vojkovich wrote: > >On Fri, 18 Oct 2002, Wojciech Kasprzak wrote: > > > >> The application used to work under Linux 7.1. Has something > >> changed in 7.3 with regard to colormap cell (pre?)allocations > >> or locking it by some X clients? How can I find which clinets > >> are allocating all the colors? On my laptop (Linux 7.1) I was > >> able to test-allocate around 130 colors before running out of > >> resources... > >> > > > > Yes, we should put this in a faq or something. The render > >extension preallocates a large chunk of the default colormap > >in depth 8 in 4.2.0 (maybe in 4.2.1 too, I don't know). This > >behavior was removed in XFree86 CVS. > > > > You mentioned you were using the "nvidia" driver. If so, > >you can add the option "NoRenderExtension" to the XF86Config file > >to disable the render extension. This option is only supported > >by the "nvidia" driver. For other drivers you'll need to use > >XFree86 CVS (or maybe 4.2.1 if the fix made it in there). > > Since this bites a lot of people wanting to use legacy apps (probably > one of the most common reasons for using depth 8 anyway), I think we > need an option to allow this preallocation of colormap entries to be > turned off. At least then people can choose what they need most -- > Render support at 8-bit, or an untouched colormap. > I just write a patch which does this today. I think also that it is a good idea to have an option which allows to control the colours that Render preallocate. I've added command lines / XF86Config options: -no-render-extension / NoRenderExtension -render-extension (for cancelling a NoRenderExtension option in XF86Config) -render-color-limit (int)cl / RenderColorLimit (int)cl I do not know if the naming is good. About the color limit arg cl it is a simple integer which replaces the default "num" of render/miindex.c which is equal to map_entries/(3 or 2). It is maybe better to allow only a few integers 0,1, ..., 6: clGreyScale PseudoColor 0 : default default 1 : 8 grey 8 grey 2 : 16 grey 2x2x2 cc + 4 grey (or 8?) 3 : 32 grey 3x3x3 cc + 8 grey (or 16?) 4 : 64 grey 4x4x4 cc + 16 grey (or 23?) 5 : 128 grey5x5x5 cc + 16 grey (or 32?) 6 : 256 grey6x6x6 cc + 32 grey (or 30) It is the first time I really read the code under Xserver so I am not sure I do the right things. Here what I do: I've added two new members to "the" ScreenRec structure: disableRender and renderColorLimit. In common/xf86Helper I've added a new function xf86SetRenderOptions(ScreenPtr) which setups these two members accordingly to the cmd line or config file option. Then, the driver should call xf86SetRenderOptions before it calls fbPictureInit. Render is disabled in fbPictureInit: if disableRender, then fbPictureInit do nothing and return TRUE. It seems to me that this is ok: the driver should works as if it has no Render support (?). At least this works with the vesa and neomagic drivers. One thing I am not really happy with is that we should add one line per driver. Maybe the two new members should be set in common/xf86Config.c (xf86HandleConfigFile). On the other hands, maybe some drivers will do not like to be compiled with RENDER, but run with renderDisabled? Or you interested? Some comments? Regards, Olivier ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Mon, Oct 21, 2002 at 06:10:26PM +0100, Alan Hourihane wrote: >On Mon, Oct 21, 2002 at 07:01:23PM +0200, Juliusz Chroboczek wrote: >> U> Does anybody know any solution around the problem of X crashing with >> U> Type1 big fonts ? >> >> The current Type 1 backend will no longer be the default in 4.3.0. >> The new Type 1 backend does not have this problem. > >There's a problem with this at the moment. If you build a static >server you get two font renderers registered to deal with .pfa/.pfb >fonts. Solution Juliusz - is it just to disable Type1 for static builds >because it's too buggy ? Unless the old Type1 backend can unreservedly be replaced by the new FreeType2 backend, then it should be disabled, and maybe even a "fake" type1 font module created for the modular build so that existing configurations don't break. If there are still reasons for wanting the old backend, then it needs to be configurable, at least at build-time. Also, I'd really like to see some resolution to the separate "FreeType" and "X-TT" backends for TrueType fonts. As it is now, if someone chooses "X-TT", they will still need the old Type1 backend for Type1 fonts regardless of other considerations. Is it still not possible to resolve the issues that led to two TrueType backends in the first place? As it is now, the first renderer registered for a suffix is the one that gets used. I'm not sure what order they're registered in right now for the static build. If we want to provide more flexibility in allowing the user to control what font suffixes are handled by what backend, there would need to be some type of run-time configurability. For the modular server this could probably be done fairly easily via the XF86Config file. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 Bugzilla
On Mon, Oct 21, 2002 at 03:54:30PM +0200, Erik Moeller wrote: >Bugzilla is quickly becoming the standard bug tracking system for large >open software projects. Originally developed by the Mozilla project, it >is now used by KDE, GNOME, Apache, AbiWord, Red Hat Linux, Conectiva >Linux, Gentoo Linux, Ximian, and many many others. XFree86, which is >fundamental to any free desktop/workstation Un*x system, doesn't have an >open bugtracking database (and, if some prior posts to this list are to >be believed, not a closed one either). > >In my humble opinion as a user, this needs to change. In a prior post to >this mailing list, Kurt Wall has already offered to set up a BTS for >XFree86: >http://www.xfree86.org/pipermail/xpert/2002-May/017211.html This comes up from time to time. The bottom line is that having an XFree86 bug tracking system is of limited use unless the XFree86 developers use it. Since that's the group that it would impact the most, that's where the motivation for it should come from. BTW, is there an official Linux kernel bug tracking system? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Mon, Oct 21, 2002 at 10:39:22PM +0100, Dr Andrew C Aitchison wrote: > On Mon, 21 Oct 2002, Alan Hourihane wrote: > > > That's probably because your loading "Type1" and "FreeType" in your > > Module section. What does your module section look like ? > > Correct. > # these 5 are fonts > # tt and freetype are mutually incompatible > # Load "tt" > Load "freetype" > Load "bitmap" > Load "speedo" > Load "type1" > > Are tt and freetype still incompatible ? Yes, and now type1 isn't needed if your using freetype. Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 22 Oct 2002 07:57, David Dawes wrote: > What is the correct way to handle headers that defined ioctls? There simply is no good way. It is conceptually wrong to install a new kernel that doesn't have the same API to userspace, and not update the rest of the system (not just the development environment - you need to recompile every binary that touches the changed interface. The same applies to a dynamically linked library. If you change the interface to the library, then you need to update all the applications using it. The best work-around I can suggest is: 1. Assume that the headers you're working with (in /usr/include) match the installed glibc. 2. Assume that the kernel you're running on is the target. 3. Assume that the header files for that kernel can be found at /usr/src/linux/include 4. Assume that the user will help you if any of the above isn't true. This is where autoconf comes in handy, because you can test each feature, and deal with one problem at a time, and you can get fine-grained user hints. My personal solution is to use a source based distribution (in my case Gentoo, but others (eg any *BSD) probably offer similar advantages. When I change the kernel and am worried about an ABI change, I just rebuild the system. But it clearly won't work for everyone. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9tHyhW6pHgIdAuOMRApzBAJ9MnI8qNVF0DhQIOYTBN0HQ0HPWQACgmnAv ZvvXtVMMWQKSPkD33ZYsPeI= =HKx1 -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]i830 refuses to run in 1400 x 1050
Hi, Let me first apologize for posting a newbie question that may have been covered before (I did search the archives and I did find some references to it, but thusfar was not able to solve my problem). I am a little ashamed (and spoilt) to admit that X is running like a charm, but that I'm just not satisfied yet since my LT has a 1400 x 1050 TFT screen and X 'only' uses 1280 x 1024 of it. The chipset in the LT is the cursed i830 (dual headed, see "No matching device for PCI:0:2:1 found"). >From the XFree86.0.log it seems that it asks the BIOS for supported resolutions and for some reason it thinks it can only do 1280 x 1024 (at least on Pipe A, whichever that may be) and hence starts up using that. Can anybody tell me if there are patches for the i810 driver to 'override' BIOS reports and blindly go into a resolution given in the XF86Config file? Maybe other improments for the i830 at this point? Hidden options? Where should I look to follow cutting-edge i810 drivers? I boot with option vga=835 (1400 x 1050 x 24, so I read) but that seems to be of no use without proper kernel support. The list of patches included for the i810 in the -72 distribution of X by RedHat: i810-dell-c400-broken-bios-1Mb-limit-workaround.patch i810-dont-force-XvMC-on-DRI-users.patch i810-dont-use-empty-for-loops-for-delays.patch i810-driver-update-cvs-20020617.patch i810-vtswitch-sync-fix.patch Maybe someone can say something sensible about the XFree86.0.log given below. Should I be concerned about the "Bad V_BIOS checksum" warning? Is X falling back to VESA instead of using the i810, or is it normal for X to query the VESA BIOS? Is it maybe because 1400 x 1050 is not a VESA standard and should I tell X not to use VESA? If so, how? Do I need the experimental /dev filesystem support in my kernel for the /dev/dri/card0 to be detected? Also, I have very little luck compiling the i830.o drm module using the -72 sources (see failed i830.o line). The make script falls out on the i810_drv (how ironic). Any clues here? System X version: 4.2.0-72 (RedHat 8 default) Kernel: 2.4.19 (home made, agp and i810 support turned on ). XFree86 Version 4.2.0 (Red Hat Linux release: 4.2.0-72) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-11smp i686 [ELF] Build Host: daffy.perf.redhat.com Module Loader present OS Kernel: Linux version 2.4.19 (root@Lappy_RH) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #24 Sat Oct 19 14:11:58 CEST 2002 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sun Oct 20 20:17:38 2002 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Anaconda Configured" (**) |-->Screen "Screen" (0) (**) | |-->Monitor "Monitor" (**) | |-->Device "Intel830" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) using VT number 7 ... (II) LoadModule: "i810" (II) Loading /usr/X11R6/lib/modules/drivers/i810_drv.o (II) Module i810: vendor="The XFree86 Project" compiled for 4.2.0, module version = 1.1.0 Module class: XFree86 Video Driver ABI class: XFree86 Video Driver, version 0.5 ... (II) I810: Driver for Intel i810 chipset: i810, i810-dc100, i810e, i815, i830M, 845G (II) Primary Device is: PCI 00:02:0 (--) Assigning device section with no busID to primary device (WW) I810: No matching Device section for instance (BusID PCI:0:2:1) found (--) Chipset i830M found ... (II) Setting vga for screen 0. (II) Loading sub module "vgahw" (II) Loading sub module "int10" ... (**) I810(0): Depth 24, (--) framebuffer bpp 32 (==) I810(0): RGB weight 888 (==) I810(0): Default visual is TrueColor (WW) I810(0): Bad V_BIOS checksum (II) I810(0): Primary V_BIOS segment is: 0xc000 (--) I810(0): Chipset: "i830" (--) I810(0): Linear framebuffer at 0x9800 (--) I810(0): IO registers at addr 0x9010 (II) I810(0): detected 8192K stolen memory. (II) I810(0): I810CheckAvailableMemory: 200700k available (==) I810(0): Will alloc AGP framebuffer: 16384 kByte (==) I810(0): Using gamma correction (1.0, 1.0, 1.0) (II) I810(0): Currently active displays on Pipe A: (II) I810(0): LFP (Local Flat Panel) child device (II) Loading sub module "vbe" ... (I
Re: [Xpert]Another CVS problem
On Mon, Oct 21, 2002 at 01:18:19AM +0200, Michel Dänzer wrote:
>On Son, 2002-10-20 at 23:57, Marc Aurele La France wrote:
>> On Sat, 19 Oct 2002, Boris wrote:
>>
>> > > > Hmm, Seems to be alot of problems in the CVS the last few days. Heres
>> > > > the latest one.
>>
>> [elided]
>>
>> > > Recently upgraded to a 2.5.42+ kernel did we? If so, harp about this on
>> > > LKML. Let me know what the outcome is.
>>
>> > Actually, I just recompiled my 2.4.20pre11 kernel and redownloaded the
>> > latest XFree cvs and I *still* get the same error when doing a "make
>> > install". Im running 2.4.20pre11, gcc 3.2, glibc 2.3.1.
>>
>> Sounds like your /usr/include/{linnux,asm} links are still pointing into
>> the 2.5.43 kernel.
>
>... but they shouldn't be links to kernel headers at all, but normal
>glibc headers. There wouldn't have been a problem in the first place
>like that.
What is the correct way to handle headers that defined ioctls?
David
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Mon, 21 Oct 2002, Alan Hourihane wrote: > That's probably because your loading "Type1" and "FreeType" in your > Module section. What does your module section look like ? Correct. # these 5 are fonts # tt and freetype are mutually incompatible # Load "tt" Load "freetype" Load "bitmap" Load "speedo" Load "type1" Are tt and freetype still incompatible ? -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Fri, Oct 18, 2002 at 08:38:22AM +0100, Philip Blacker wrote: >>> I'm wondering if it's feasible for the kernel to route ACPI power >>>management events to the corresponding APM events through /dev/apm >>>(optionally, of course) for some sort of ACPI to APM backwards >>>compatibility for some apps that use /dev/apm (like XFree86). >>>Otherwise somebody will have to add /dev/acpi support to XFree86. > >>It might be feasible to do this in user space too with a daemon that >>listens on /dev/acpi and delivers translated events on /dev/apm. >>Ultimately we probably want to add ACPI support to XFree86 so that it >>can take full advantage of what ACPI offers over APM. > >>I think the original poster mentioned swsusp, which I thought was >>independent of APM and ACPI? I don't know what (if any) mechanism it >>uses to inform interested user-space applications that a suspend has >>been initiated. Either the X server needs to be informed about the >>suspend and resume so that it can do what needs to do, or have >something >>else does get informed use chvt(1) to make the X server VT switch to >>a text console on suspend and switch back on resume. I think the chvt > >>method is what people used before XFree86 had support for monitoring >>APM events. > >>David > >Swsusp is totally independant of ACPI and APM, although it can be >called by either. I am not sure if it fires an APM or ACPI event if >these are enabled. > >Through the swsusp mailing list it has been esatblished that the prblem >is with XAA, or more specifically with one XAA function, >SolidTwoPointLine. If this is disabled everything works correctly. It >apears that the hardware acceleration gets confused during the suspend/ >resume cycle. Does it make a difference if you switch to a text VT before initiating a suspend? That's how XFree86 handles APM suspend/resume. With a correctly implemented VTEnter(), the driver should then reinitalise the hardware correctly when switching back to the X server after resuming. Some drivers don't to enough hw state initialisation in their VTEnter() function to handle returning from suspend. All of this assumes that the BIOS (and OS?) put the video hardware back into a sane text console state -- ideally the same state as after a normal system boot. If that doesn't happen, then there are likely to be problems. >It has also been reported that when using the closed source driver, >patched so that is does not block power management events, the 3d >functinality does not work immediately after resume but will start >working some time later. This would imply that there is a problem with >the nvidia hardware after a resume that requires some form of reset. > >Another way to solve the problem is to start another Xserver on another >display then kill it. This probably does the reset that should come >though APM. > >Is there a way for a user space program to signal to the X server that >a suspend is about to happen or that a resume has happend to enable >this reset to be done more cleanly. Currently the X server only monitors the APM device for power management events. If swsusp can use some equivalent of apmd (or acpid), it should be possible to have that daemon force a VT switch on suspend, and switch back on resume (using chvt(1) as I suggested above). >I think adding ACPI support to XFree86 is the way to go rather than a >user space deamon. Kernel 2.4.20 is going to have a (almost) fully >working ACPI implementation, the swsusp patch will still be needed for >S4(suspend to disk), S1 (suspend to RAM) will work on some machines. What's the current state of acpid? David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Patch for the Xlib i18n code
On Mon, Oct 21, 2002 at 03:14:47PM +0200, Egbert Eich wrote: > > I have some more patches for omGeneric.c. > So I will take care of your fixes. Thanks. > Thanks to have applied my patch! Just one note without real importance, my name is Chapuis and not Chapius :o) Regards, Olivier ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with mga G450 and Overlay mode (8+24)
On Mon, 21 Oct 2002, Russ Radke wrote: > Folks, > > I'm running a mga G450 in a P4 system with XFree86 4.2.0-8 (RedHat), > and I can't seem to get into overlay mode (8+24). IIRC mga_hal_drv.o doesn't support overlay mode; are you using the HAL ? > (**) MGA(0): Option "Overlay" "on" > (--) MGA(0): Chipset: "mgag400" > (==) MGA(0): Using AGP 1x mode > (**) MGA(0): "on" is not a valid value for Option "Overlay" The options for Option "Overlay" and optional :-), and are something like "8+24" and "24+8". The idea may have been to set the default visual, but I don't know for sure, and I just use Option "Overlay" on my G550, as well as my Millennium I. You aren't using -fbbpp 24 are you ? I'll have a look at the full config and log file if you send them to me. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Backing store on Radeon?
Ian Romanick wrote: On Sun, Oct 20, 2002 at 05:09:08PM -0600, Jens Owen wrote: Making a direct rendering 3D driver render to a windows backing store area is a complicated task with very little benefit, IMO. Right, but shouldn't purely 2D targets work? I wouldn't think that the menus in twm are using OpenGL. :) At the very least, if it's not supported at all, when X is started with +bs, shouldn't it say just say no? That's the problem that I see. The user requests a feature, X says it's okay, but then it's not implemented. TWM isn't a good example, because it can efficiently handle expose events without the klunky backingstore feature enabled. Granted, there exists a small subset of applications that benefit from backing store, but it's a very small set in my experience. Most of the 2D applications that can't handle redraws can often achieve the same effect by rendering to pixmaps. Would disabling the DRI when backingstore is enabled give the semantic consistency you're looking for? I don't have a problem with that, because 99.99% of the users don't need backing store enabled. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Backing store on Radeon?
On Mon, Oct 21, 2002 at 10:06:13AM -0600, Jens Owen wrote: > Ian Romanick wrote: > > On Sun, Oct 20, 2002 at 05:09:08PM -0600, Jens Owen wrote: > >>Making a direct rendering 3D driver render to a windows backing store > >>area is a complicated task with very little benefit, IMO. > > > > Right, but shouldn't purely 2D targets work? I wouldn't think that the > > menus in twm are using OpenGL. :) At the very least, if it's not supported > > at all, when X is started with +bs, shouldn't it say just say no? That's > > the problem that I see. The user requests a feature, X says it's okay, but > > then it's not implemented. > > TWM isn't a good example, because it can efficiently handle expose > events without the klunky backingstore feature enabled. Granted, there > exists a small subset of applications that benefit from backing store, > but it's a very small set in my experience. Most of the 2D applications > that can't handle redraws can often achieve the same effect by rendering > to pixmaps. I was just using that as an example the shows the bug I saw. With '+bs' on Radeon, the (left-mouse-click) menu is blank until you move the mouse pointer over each of the menu items. > Would disabling the DRI when backingstore is enabled give the semantic > consistency you're looking for? I don't have a problem with that, > because 99.99% of the users don't need backing store enabled. I don't think that would help. I commented out the 'Load "dri"' and 'Load "glx"' lines from my XF86Config file and got the same behavior. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 CVS and 1600x1024 (DVI) / Radeon
I tried to send this a few days ago but it looks like it may not have made it (never saw it come back across the list), so I'll try again. Apologies if it actually made it. With the flurry of commits over the last few weeks, I figured it would be worth installing XFree86 CVS and check out RandR, Xcursor and the new ATI acceleration. Unfortunately, X comes up with a root window size of 1600x1024 (reported by xdpyinfo) but is really only outputting 1280x1024 (reported by my SGI MultiLink adapter). All of this flows through a Radeon VE to my SGI 1600SW flat panel (DVI). Any ideas? Oh, and just to put every question in a single e-mail, thus making it difficult to find in mailing list archives, even in 24bpp, pixmaps appear to be 16bpp. My web page, for example, looks substantially different between my S3 based notebook in 24bpp and my Radeon VE based desktop in 24bpp. Is there a pixmap depth limitation in the radeon driver? I've attached the usual XFree86 logs for completeness. Jeff This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 15 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-xfs i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Thu Oct 17 23:48:57 2002 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Anaconda Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Radeon VE" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) FontPath set to "unix/:7100" (**) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6-CVS/lib/modules" (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6-CVS/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.2.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6-CVS/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1130 card 1043,8027 rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1131 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:1e:0: chip 8086,244e card , rev 01 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,2440 card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,244b card 1043,8027 rev 01 class 01,01,80 hdr 00 (II) PCI: 00:1f:2: chip 8086,2442 card 1043,8027 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1f:3: chip 8086,2443 card 1043,8027 rev 01 class 0c,05,00 hdr 00 (II) PCI: 00:1f:4: chip 8086,2444 card 1043,8027 rev 01 class 0c,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5159 card 1002,013a rev 00 class 03,00,00 hdr 00 (II) PCI: 02:0a:0: chip 11ad,0002 card 1385,f004 rev 20 class 02,00,00 hdr 00 (II) PCI: 02:0c:0: chip 1274,5000 card 4942,4c4c rev 01 class 04,01,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,2), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0
Re: [Xpert]Problems with Type1 big fonts
U> Does anybody know any solution around the problem of X crashing with U> Type1 big fonts ? The current Type 1 backend will no longer be the default in 4.3.0. The new Type 1 backend does not have this problem. U> Any other solution ? Get the new FreeType driver from XFree86 CVS and recompile it for your system. Or else switch to current CVS. Sorry, there are no easier solutions at this time. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 Bugzilla
On Mon, Oct 21, 2002 at 03:54:30PM +0200, Erik Moeller wrote: > Bugzilla is quickly becoming the standard bug tracking system for large > open software projects. Originally developed by the Mozilla project, it > is now used by KDE, GNOME, Apache, AbiWord, Red Hat Linux, Conectiva > Linux, Gentoo Linux, Ximian, and many many others. XFree86, which is > fundamental to any free desktop/workstation Un*x system, doesn't have an > open bugtracking database (and, if some prior posts to this list are to > be believed, not a closed one either). > > In my humble opinion as a user, this needs to change. In a prior post to > this mailing list, Kurt Wall has already offered to set up a BTS for > XFree86: > http://www.xfree86.org/pipermail/xpert/2002-May/017211.html > > I suggest that someone in authority should contact Kurt > (kwall at kurtwerks dot com) and ask him if he is still up to the task. > A Bugzilla system would greatly benefit X' further development. The offer still stands. I haven't pushed the issue because I'm not otherwise involved with XFree86 development. My desire is simply to facilitate, accelerate, and streamline-ate (I had to get that -ate in there for parallelism) the development process. I can also be reached at my day job, should someone decide to contact me (kurt dot wall at timesys dot com). Kurt -- "Protozoa are small, and bacteria are small, but viruses are smaller than the both put together." ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VT switch
Michel =?ISO-8859-1?Q?D=E4nzer?= writes: > > However I still don't see where BM might get disabled > > explicitely when it had been enabled when the server > > was first started. > > Does it matter? Anything could disable BM while we're switched away... > > It was posted that this happened while X was active. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Mon, Oct 21, 2002 at 07:01:23PM +0200, Juliusz Chroboczek wrote: > U> Does anybody know any solution around the problem of X crashing with > U> Type1 big fonts ? > > The current Type 1 backend will no longer be the default in 4.3.0. > The new Type 1 backend does not have this problem. There's a problem with this at the moment. If you build a static server you get two font renderers registered to deal with .pfa/.pfb fonts. Solution Juliusz - is it just to disable Type1 for static builds because it's too buggy ? Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
On Mon, Oct 21, 2002 at 12:47:42PM -0400, Wojciech Kasprzak wrote: > > > > I do not think that XFree cvs will solve allocation pbs in general. If > > you start your server with XRender (which allocate "only" 85 colors) > > and then start, says, a kde application (without limiting the colors > > to 64) then almsot surly all the colours will be allocated. So your > > application will be unusable without a private cmap. About read-only > > color in PseudoColor mode, I suggest to take the more close colour in > > the used colormap if XAllocColor fail. > > > > Regards, Olivier > > > > Olivier, > > Thanks for advice. I have tested a private colormap, > but I would prefer to use the system map. The "NoRenderExtension" > option in the nvidia driver makes it possible, but I still need > to close other system apps to get started (Konqueror is a real > killer). You suggest "limiting the colors to 64" in KDE apps. > I'd like to try it. How/where do I set this limit? > Hum ... I was maybe a bit optimistic: [olivier@snoopy olivier]$ konqueror --help-qt << SNIP >> --cmapCauses the application to install a private color map on an 8-bit display. --ncolsLimits the number of colors allocated in the color cube on an 8-bit display, if the application is using the QApplication::ManyColor color specification. Unfortunately, it does not seem that --ncols works here for KDE apps (maybe a K developer can comment on this). The --cmap option works :o/ Maybe adding one line in the good config file will allow color limitation in KDE. I think this possible with GTK (do not how) and FVWM. Regards, Olivier ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
I have compiled XFree86 from CVS many many times and I havent had this
problem before. The only major update I had was installing the latest Glibc
2.3.1. I know their are some major changes in that release.
- Original Message -
From: "Marc Aurele La France" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, October 21, 2002 9:44 AM
Subject: Re: [Xpert]Another CVS problem
> On 21 Oct 2002, Michel Dänzer wrote:
>
> > On Son, 2002-10-20 at 23:57, Marc Aurele La France wrote:
> > > On Sat, 19 Oct 2002, Boris wrote:
>
> > > > > > Hmm, Seems to be alot of problems in the CVS the last few days.
Heres
> > > > > > the latest one.
>
> > > [elided]
>
> > > > > Recently upgraded to a 2.5.42+ kernel did we? If so, harp about
this on
> > > > > LKML. Let me know what the outcome is.
>
> > > > Actually, I just recompiled my 2.4.20pre11 kernel and redownloaded
the
> > > > latest XFree cvs and I *still* get the same error when doing a "make
> > > > install". Im running 2.4.20pre11, gcc 3.2, glibc 2.3.1.
>
> > > Sounds like your /usr/include/{linnux,asm} links are still pointing
into
> > > the 2.5.43 kernel.
>
> > ... but they shouldn't be links to kernel headers at all, but normal
> > glibc headers. There wouldn't have been a problem in the first place
> > like that.
>
> That the new header is being picked up seems the only viable explanantion
> for the reported symptom. How it got there is irrelevant. Perhaps
> re-installing glibc from source re-syncs the headers, I don't know. Or,
> possibly, this system simply does not implement the glibc/kernel version
> skew some distributions are so prone to.
>
> Marc.
>
> +--+---+
> | Marc Aurele La France | work: 1-780-492-9310 |
> | Computing and Network Services | fax:1-780-492-1729 |
> | 352 General Services Building | email: [EMAIL PROTECTED] |
> | University of Alberta +---+
> | Edmonton, Alberta | |
> | T6G 2H1 | Standard disclaimers apply|
> | CANADA | |
> +--+---+
> XFree86 Core Team member. ATI driver and X server internals.
>
> ___
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
>
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Backing store on Radeon?
On Sun, Oct 20, 2002 at 05:09:08PM -0600, Jens Owen wrote: > Ian Romanick wrote: > > Warning: ignorant questions on the way... > > > > I've gotten some questions from a couple of people about backing store with > > DRI, on the R100 driver specifically. Because my background isn't firmly > > rooted in X-Windows, I wasn't really familiar with what that meant. :) I > > did a little searching, and I think I have a vauge idea now. > > > > In any case, as near as I can tell, when the Radeon DRI driver gets loaded, > > backing store is explicitly disabled. Why is that? Is it a hardware > > limitation or is it "just" to conserve memory? Something else? > > Ian, > > Sorry about the late response. I hope this is still useful. > > Backing Store is a "feature" in X that allows the contents of windows to > be preserved even when they are obscured. The benefit of this feature > is the application should not receive expose events from the server when > a window is uncovered. However, the implementation of backingstore > within the X Server puts the burden on the drivers to render to both the > exposed areas on the screen *and* to the saved areas of backing store > which I belive are implemented as a pixmap...which can reside in > offscreen memory or the X Server's system allocated memory. Okay, that's pretty much what I thought it did. There was a similar feature in the Amiga windowing system back in the day, but I won't go there. :) > Making a direct rendering 3D driver render to a windows backing store > area is a complicated task with very little benefit, IMO. Right, but shouldn't purely 2D targets work? I wouldn't think that the menus in twm are using OpenGL. :) At the very least, if it's not supported at all, when X is started with +bs, shouldn't it say just say no? That's the problem that I see. The user requests a feature, X says it's okay, but then it's not implemented. -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: r200 and libxaa
On Mon, Oct 21, 2002 at 12:30:24PM +0200, Michel Dänzer wrote: >For your reference, here's what I committed to DRI CVS. The check for >the XAA minor version could probably be done more elegantly in XFree86 >CVS though. Adding checks like that to the XFree86 CVS version isn't encouraged, because compatibility in that direction isn't guaranteed (and where do you draw the line with regard to making new driver modules work with old X servers and other modules?) The xf86GetModuleVersion() function was added after 4.2 to make this easier in other environments though. There's an example that uses it in the i810 driver in the DRI CVS, but I omitted that check for the version in the XFree86 CVS. Compatibility in the other direction is important though, and moving the new struct fields to the end should address that in this case. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia and Suspend
On Sun, Oct 20, 2002 at 02:52:16PM -0700, Mark Vojkovich wrote: > On Fri, 18 Oct 2002, Philip Blacker wrote: > > > >> I'm wondering if it's feasible for the kernel to route ACPI power > > >>management events to the corresponding APM events through /dev/apm > > >>(optionally, of course) for some sort of ACPI to APM backwards > > >>compatibility for some apps that use /dev/apm (like XFree86). > > >>Otherwise somebody will have to add /dev/acpi support to XFree86. > > > > >It might be feasible to do this in user space too with a daemon that > > >listens on /dev/acpi and delivers translated events on /dev/apm. > > >Ultimately we probably want to add ACPI support to XFree86 so that it > > >can take full advantage of what ACPI offers over APM. > > > > >I think the original poster mentioned swsusp, which I thought was > > >independent of APM and ACPI? I don't know what (if any) mechanism it > > >uses to inform interested user-space applications that a suspend has > > >been initiated. Either the X server needs to be informed about the > > >suspend and resume so that it can do what needs to do, or have > > something > > >else does get informed use chvt(1) to make the X server VT switch to > > >a text console on suspend and switch back on resume. I think the chvt > > > > >method is what people used before XFree86 had support for monitoring > > >APM events. > > > > >David > > > > Swsusp is totally independant of ACPI and APM, although it can be > > called by either. I am not sure if it fires an APM or ACPI event if > > these are enabled. > > > > Through the swsusp mailing list it has been esatblished that the prblem > > is with XAA, or more specifically with one XAA function, > > SolidTwoPointLine. If this is disabled everything works correctly. It > > apears that the hardware acceleration gets confused during the suspend/ > > resume cycle. > >The bios does something to the hardware when it goes into suspend > that messes up the graphics engine state. At this time, I don't know > what it is that it does. swsusp is a legacy interface to implement suspend-to-disk feature to linux. No APM call is then done. ACPI (only in linux 2.5) use this legacy interface to implement S4, and call the necessary (as for example the _PTS ASL Methods before suspension, _WAK after resuming, etc) No such things is done, though in linux 2.4 + swsusp. Please note that the same trouble can occur with FreeBSD current, with a S4BIOS suspend/resume cycle, and yes, a system state snapshoot is done by the BIOS in that case. > > > > > It has also been reported that when using the closed source driver, > > patched so that is does not block power management events, the 3d > > functinality does not work immediately after resume but will start > > working some time later. This would imply that there is a problem with > > the nvidia hardware after a resume that requires some form of reset. > >Same problem. Bios messes things up and we have no way of > knowing about it. In the case of the binary drivers it's not safe > to run with the power management unblocked because when the bios > messes with the hardware it can do things that effect the kernel > module in a fatal way (lost interrupts and the like). > It is possible to inform the binary driver that a suspension can occur via ACPI. The function RmPowerManagement() in the binary portion were supposed to be called by ACPI. This function seems to be in the NVIDIA_kernel-1.0.2314 release, but is now removed. If this function is (re)implemented for linux 2.5, suspend/resume via ACPI can be done for this card. Please note also that there were efforts to have proper suspend/resume under ACPI with the help of drm for other cards. Cheers, -- Ducrot Bruno http://www.poupinou.orgPage profaissionelle http://toto.tu-me-saoules.com Haume page ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] Backing store on Radeon?
Ian Romanick wrote: On Mon, Oct 21, 2002 at 10:06:13AM -0600, Jens Owen wrote: Would disabling the DRI when backingstore is enabled give the semantic consistency you're looking for? I don't have a problem with that, because 99.99% of the users don't need backing store enabled. I don't think that would help. I commented out the 'Load "dri"' and 'Load "glx"' lines from my XF86Config file and got the same behavior. Apologies. When I saw your question originally posted to the dri-devel list, I assumped it was related to direct rendering. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 CVS and 1600x1024 (DVI) / Radeon
On Mon, 21 Oct 2002, Jeff Brubaker wrote: > Unfortunately, X comes up with a root window size of 1600x1024 (reported by > xdpyinfo) but is really only outputting 1280x1024 (reported by my SGI > MultiLink adapter). All of this flows through a Radeon VE to my SGI 1600SW > flat panel (DVI). When I was looking for a dvi card for my SGI 1600SW, I thought I read that the Radeon didn't official support that resolution; maybe the driver now supports the resolution limit on the card :-( > Oh, and just to put every question in a single e-mail, thus making it > difficult to find in mailing list archives, even in 24bpp, pixmaps appear to > be 16bpp. My web page, for example, looks substantially different between my > S3 based notebook in 24bpp and my Radeon VE based desktop in 24bpp. Is there > a pixmap depth limitation in the radeon driver? That log file says that the config file requested 16bpp :-) It also says that it is using the DAC in 6bit mode, which would not help. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On 21 Oct 2002, Michel Dänzer wrote:
> On Son, 2002-10-20 at 23:57, Marc Aurele La France wrote:
> > On Sat, 19 Oct 2002, Boris wrote:
> > > > > Hmm, Seems to be alot of problems in the CVS the last few days. Heres
> > > > > the latest one.
> > [elided]
> > > > Recently upgraded to a 2.5.42+ kernel did we? If so, harp about this on
> > > > LKML. Let me know what the outcome is.
> > > Actually, I just recompiled my 2.4.20pre11 kernel and redownloaded the
> > > latest XFree cvs and I *still* get the same error when doing a "make
> > > install". Im running 2.4.20pre11, gcc 3.2, glibc 2.3.1.
> > Sounds like your /usr/include/{linnux,asm} links are still pointing into
> > the 2.5.43 kernel.
> ... but they shouldn't be links to kernel headers at all, but normal
> glibc headers. There wouldn't have been a problem in the first place
> like that.
That the new header is being picked up seems the only viable explanantion
for the reported symptom. How it got there is irrelevant. Perhaps
re-installing glibc from source re-syncs the headers, I don't know. Or,
possibly, this system simply does not implement the glibc/kernel version
skew some distributions are so prone to.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax:1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +---+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply|
| CANADA | |
+--+---+
XFree86 Core Team member. ATI driver and X server internals.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Re: r200 and libxaa
On Mon, Oct 21, 2002 at 08:56:57AM -0400, Kevin E Martin wrote: >I admit I didn't think through all of the implications of the XAA >change, but, rather, I put the new items in the XAAInfoRec where they >logically should go -- next to the functions they effect. Michel caught >my oversight and has fixed the problem, but only in the DRI CVS tree. >When Michel sends patches back to XFree86, I will incorporate them. >And, I've asked him in private e-mail just last week to do exactly that. >I have not fixed this problem in the XFree86 tree yet since I'm waiting >either for a DRI/XFree86 resync or for patches to be sent in. > >In general, this is one of those "DRI CVS tree and XFree86 CVS tree have >greatly diverged problems", which will hopefully be fixed soon when the >two trees are resynced. This resync is currently being planned and will >hopefully happen sometime soon. Compatibilty problems like this should be fixed as soon as they're found rather than waiting for resyncs. Otherwise, as in this case, they cause mysterious problems for others trying to use the current XFree86 CVS. Mark committed the relevant fix last night. David ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problems with Type1 big fonts
On Mon, 21 Oct 2002, Alan Hourihane wrote: > On Mon, Oct 21, 2002 at 07:01:23PM +0200, Juliusz Chroboczek wrote: > > U> Does anybody know any solution around the problem of X crashing with > > U> Type1 big fonts ? > > > > The current Type 1 backend will no longer be the default in 4.3.0. > > The new Type 1 backend does not have this problem. > > There's a problem with this at the moment. If you build a static > server you get two font renderers registered to deal with .pfa/.pfb > fonts. Solution Juliusz - is it just to disable Type1 for static builds > because it's too buggy ? I think the module server does that too; I get Warning: font renderer for ".pcf" registered more than once Warning: font renderer for ".pcf.Z" registered more than once Warning: font renderer for ".pcf.gz" registered more than once Warning: font renderer for ".snf" registered more than once Warning: font renderer for ".snf.Z" registered more than once Warning: font renderer for ".snf.gz" registered more than once Warning: font renderer for ".bdf" registered more than once Warning: font renderer for ".bdf.Z" registered more than once Warning: font renderer for ".bdf.gz" registered more than once Warning: font renderer for ".pmf" registered more than once Warning: font renderer for ".pfa" registered more than once Warning: font renderer for ".pfb" registered more than once in my log at the moment. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 Bugzilla
Bugzilla is quickly becoming the standard bug tracking system for large open software projects. Originally developed by the Mozilla project, it is now used by KDE, GNOME, Apache, AbiWord, Red Hat Linux, Conectiva Linux, Gentoo Linux, Ximian, and many many others. XFree86, which is fundamental to any free desktop/workstation Un*x system, doesn't have an open bugtracking database (and, if some prior posts to this list are to be believed, not a closed one either). In my humble opinion as a user, this needs to change. In a prior post to this mailing list, Kurt Wall has already offered to set up a BTS for XFree86: http://www.xfree86.org/pipermail/xpert/2002-May/017211.html I suggest that someone in authority should contact Kurt (kwall at kurtwerks dot com) and ask him if he is still up to the task. A Bugzilla system would greatly benefit X' further development. For the record, the official Bugzilla homepage is at: http://www.bugzilla.org/ Sincerely, Erik Moeller -- FOKUS - Fraunhofer Insitute for Open Communication Systems Project BerliOS - http://www.berlios.de ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap Allocation problems under Linux 7.3
> > I do not think that XFree cvs will solve allocation pbs in general. If > you start your server with XRender (which allocate "only" 85 colors) > and then start, says, a kde application (without limiting the colors > to 64) then almsot surly all the colours will be allocated. So your > application will be unusable without a private cmap. About read-only > color in PseudoColor mode, I suggest to take the more close colour in > the used colormap if XAllocColor fail. > > Regards, Olivier > Olivier, Thanks for advice. I have tested a private colormap, but I would prefer to use the system map. The "NoRenderExtension" option in the nvidia driver makes it possible, but I still need to close other system apps to get started (Konqueror is a real killer). You suggest "limiting the colors to 64" in KDE apps. I'd like to try it. How/where do I set this limit? Thnaks, Voytek __ Wojciech (Voytek) Kasprzak e-mail: [EMAIL PROTECTED] WWW: www-lecb.ncifcrf.gov/~kasprzak __ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
