Re: [Xpert]Pb with ATI Radeon FireGL 7800 & RedHat 8.0 on IBMThinkpad A31p
On Sam, 2002-12-14 at 02:09, Thomas Deschamps wrote: > > I am an absolute beginner in the management of linux on my laptop, but I > came to the conclusion that there might be a pb with the driver for my card. > First of all, incriminated objects are: > IBM A31p with ATI Radeon Mobility FireGL 7800 > RedHat 8.0 (XFree86-4.2.0-72) > > I have some problems with my C++ code using OpenGL. In particular, I > cannot sometimes display all the objects in a 3d rendered scene. > Since it is difficult to explain it, I've put a picture of this > rendering problem there: > http://math.lbl.gov/~deschamp/pb_ibma31p_fireGL7800.jpg > <http://math.lbl.gov/%7Edeschamp/pb_ibma31p_fireGL7800.jpg> You could try DRI snapshots from http://dri.sf.net and post to [EMAIL PROTECTED] if the problem persists. Or you could try ATI's binary only drivers. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 8500 driver. Open Source?
On Son, 2002-12-29 at 10:19, Brian Lavender wrote: > Is support for the ATI Radeon 8500 coming in Open Source? Yes, 3D support will be in XFree86 4.3.0, if you can't wait for that see http://dri.sf.net or http://xfree86.org/cvs/ . -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Misterious X-server reboot
On Don, 2002-12-12 at 23:33, Alejandro Lorenzo Gallego wrote: > Hi, i'am using Xfree 4.2.1 (recentrly updated to see if the problem went away > with this) and mainly KDE 3.0.3 > > The thing is that; after a time o _perfect_ work of the X server; it, without > any kind of predictability reboots. Well, the true is that in many cases, the > reboot cames when you push a key, or click with the mous; but the misterious > is that it reboots randomly. And, besides, it leaves no log after; it simply > "choff" and the kdm interface came up inmediatly (just as i have just started > the box) Sounds like the X server crashes, and kdm spawns another one. Using startx or xinit instead might give a hint about the cause of the crash, a common problem is the TrueType font renderer modules like freetype. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]grey stipple background
On Die, 2002-12-24 at 01:39, Dave Airlie wrote: > I'm working on using Xfree in an embedded application and I want to not > have the grey stippled background show up on boot.. I want the screen to > stay black until I draw something to it ... In current CVS the server supports the -br command line option for this. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]without "AllowMouseOpenFail" causes X _keyboard_ tofail silently if _mouse_ is not plugged in
On Fre, 2002-12-20 at 14:54, Frank Murphy wrote: > > >From what I understand, the AllowMouseOpenFail will allow me to keep the PS/2 > mouse configured without having one plugged in. I plan to add that to my > XFConfig, but it seems that allowing a mouse to fail open should be the > default (especially a second mouse). That option only has an impact if the server fails to start without it. See a recent Xpert post by Egbert Eich for a possible explanation of the problem. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Dual Head, DVI-D, Radeon 9000
On Fre, 2002-12-20 at 15:28, William Gallafent wrote: > > Having used fglrxconfig and tweaked the file produced to have the > correct BusID, I almost have a working set up. That is, the server > starts up fine, with a screen size of 2048x768, and the left half of > that screen displayed on the monitor attached to the VGA > connector. The problem is that the second head doesn't display > anything - just says 'No connection - check signal cable'. > > So, I suspect that everything is working except that the actual DVI-D > output hardware is not being switched on. Is this the likely cause, > and if so, how can I go about fixing it? (I'm willing to dabble / > test...). Or is there some other problem? > > Is the problem likely to be fixed by upgrading to current XFree86 CVS, I think so. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: DRM: possible DoS for vblank signals
On Don, 2002-12-19 at 14:39, Michel Dänzer wrote: > Currently, an arbitrary number of signals can be scheduled, potentially > exhausting kernel memory and/or causing lots of useless list traversal > in the interrupt handler. I guess the number of pending signals needs to > be limited, or is there a better way to handle this? http://penguinppc.org/~daenzer/DRI/drm-vblank-signal-nodos.diff limits the number of pending signals to 100 and only schedules a given signal for a given sequence number to a given process once. Feedback appreciated. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]DRM: possible DoS for vblank signals
Currently, an arbitrary number of signals can be scheduled, potentially exhausting kernel memory and/or causing lots of useless list traversal in the interrupt handler. I guess the number of pending signals needs to be limited, or is there a better way to handle this? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]radeon dual head problem
On Mit, 2002-12-18 at 19:31, Frank Van Damme wrote: > > - when I start x (with startx without argumante) all I get is this: > > 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.2 (DRI trunk) / X Window System > (protocol Version 11, revision 0, vendor release 6600) > Release Date: 21 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 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.1.log", Time: Wed Dec 18 12:24:03 2002 > (==) Using config file: "/etc/X11/XF86Config-4" > (WW) RADEON: No matching Device section for instance (BusID PCI:1:0:0) found > (EE) Screen 0 deleted because of no matching config section. > (EE) Device(s) detected, but none match those in the config file. Have you tried "PCI:1:0:0" for the bus ID instead of just "1:0:0"? If that doesn't help, please provide the log file. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 9000 + Xinerama
On Mon, 2002-12-16 at 05:40, Sean Adams wrote: > > Can anyone help with using the new Radeon9000 driver support with > Xinerama? The setup is as follows: > > One AGP Nvidia 4400 (middle display) > Two PCI Radeon 9000s (left and right displays) > All displays at 1600x1200 (DVI) > Latest X from CVS > Binary drivers from Nvidia > Linux 2.4.19-16mdk > > Here's the config: > > http://www.seanadams.com/x/XF86Config-4 > > If I try to start with all three displays enabled, X dumps core with a > bunch of warnings about unresolved symbols (I'm aware that these are not > necessarily a problem). Here's the log with all three displays enabled: > > http://www.seanadams.com/x/allthree.log > > If I disable *either* of the ATI cards, everything works fine with just > two heads. Here's a log of that, with just middle and left screens > enabled: > > http://www.seanadams.com/x/justtwo.log > > Disabling the Nvidia card doesn't make any difference. I also tried > putting one of the ATI cards in a different slot, and verifying that > they're not sharing an IRQ. Sounds like multi card Xinerama is broken in the radeon driver to me, but: does not loading the glx module make a difference? What about specifying "radeon" for driver instead of "ati"? Not that I expect these to make a difference... > Now there's one other thing I should mention, but it's probably a red > herring: before upgrading to the current CVS source, I was using V4.2.0. > After upgrading, the new version was not able to find its libraries until > I exported LD_LIBRARY_PATH="/usr/X11R6/lib". The old version didn't need > this... how come? Did I miss a compile-time option? Is this related to the > unresolved symbol stuff above? No. Do you have /usr/X11R6/lib in /etc/ld.so.conf and run ldconfig since installing from CVS? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Linux driver for ATI MP-6: any hope?
On Sam, 2002-12-14 at 19:32, [EMAIL PROTECTED] wrote: >Sender: [EMAIL PROTECTED] >Date: Sat, 14 Dec 2002 12:06:30 -0500 >From: Kevin Brosius <[EMAIL PROTECTED]> > >[EMAIL PROTECTED] wrote: > >> I'm having a lot of trouble getting X to run on my Toshiba Satellite >> 1905-S301 laptop... > >Here's the culprit. You need a driver that supports this chipset. > >> (--) PCI:*(1:0:0) ATI unknown chipset (0x4c59) rev 0, Mem @ 0xf000/27, >0xe800/16, I/O @ 0x3000/8 > >Current xfree86 cvs identifies that chip as PCI_CHIP_RADEON_LY > >(http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h?rev=1.138&content-type=text/x-cvsweb-markup) >so may be usable on that machine. I don't know if the driver supports >though. > > Thank you very much. That's a big clue, although it also means that > I'm in big trouble... > > The drivers situation in this case appears to be pretty hopeless. The > chip is an ATI M6-P (Mobility). ATI does not give out or sell drivers > for it to the public (it directs users to the laptop's manufacturer, > which in the case of Toshiba is a dead end). > > I write to the list in the hope that the situation may be less bleak > than it looks from my (very ignorant) viewpoint. Is it possible to > find a Linux driver for this chip? The M6 LY has been supported by XFree86 since 4.2.0, or am I missing something? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon ATI Mobility 7500
On Mon, 2002-12-09 at 23:35, Eric Plaster wrote: > Ok, I got a Dell Latitude C640 with a Radeon ATI Mobility 7500 and > loaded it with RH8.0. I upgraded the kernel to rawhide kernel > kernel-2.4.19-0.pp.20. I upgraded my XFree86 to Mike Harris' > development release of 4.2.99.2-0.20021126.10. > > When I was using the RH8 XFree86 version of 4.2 I could get 800x600 on > my external monitor (vga port off the back of the laptop). Now, I can > only do 640x480. My monitor is a Dell P991 and can do 1600x1200. It is > having problems reading in my hsync/vrefresh range, as you can see from > this part of the log: > > (WW) RADEON(0): Monitor0: Using default hsync range of 28.00-33.00kHz > (WW) RADEON(0): Monitor0: using default vrefresh range of 43.00-72.00Hz As DDC doesn't seem to work with your external monitor, you may need to provide the refresh ranges it supports with Options "CloneHSync" and "CloneVRefresh". -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Getting second mirrored monitor to refresh properlywith a radeon
On Mon, 2002-12-09 at 16:33, Ti Leggett wrote: > You are correct that it was an October build. I downloaded the latest > December binaries but they were apparently compiled against cvs X so > they don't work with my 4.2.0 installation. As explained in http://dri.sourceforge.net/doc/install_readme.txt, you may need to install the extras package as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Getting second mirrored monitor to refresh properlywith a radeon
On Fre, 2002-12-06 at 21:05, Ti Leggett wrote: > So I tried radeon-20021012 and got different but no better results.. That's October 12th, right? > On Fri, 2002-12-06 at 09:18, Michel Dänzer wrote: > > > > You should try a later dri-radeon snapshot, from November at least. The > > driver has improved a lot in that area. Your logs show an older driver, maybe even not from a DRI snapshot at all. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Getting second mirrored monitor to refresh properlywith a radeon
On Don, 2002-12-05 at 21:42, Ti Leggett wrote: > I have an IBM T30 laptop that has a Radeon 7500 (M7 LW) built in. What > I'm trying to do is make it so that when I dock at my desk I can use my > 19 inch monitor instead of the LCD. Right now, when I plug it in, it > mirrors, but the refresh is set at 55kHz/50Hz. Obviously this is way too > low to be good on the ole eyes. I tried bumping up the sync and refresh > rates in my config as well as adding a specific modeline for my > resolution and targeted refresh (1400x1050 @ 80Hz). All to know avail. > It seems to detect the LCD and ignore the CRT all together. > > Any suggestions would be appreciated! > > I'm running: > RedHat 7.3 > XFree86 4.2.0 > dri-radeon 20020907 You should try a later dri-radeon snapshot, from November at least. The driver has improved a lot in that area. > If it helps, I'll attach my XF86Config-4 file later. If that doesn't help, the log file would be interesting as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problem with ATI Radeon 7000
On Fre, 2002-12-06 at 11:17, Matthias Meixner wrote: > > since I have not found an archive of this list, I do not know, if there > is already a solution for the following problem: > > There seems to be a problem with the acellerated rendering of filled > circles and ellipses using a radeon 7000 based graphics card, they turn out > black independend of the color chosen. There is a simple test to check this: > >Try to draw a filled circle using xfig. Very small ones turn out OK, but >larger ones become all black. This does not happen using other graphics >cards, so I think it is a fault of the driver for the radeon chipset. > > I am using XFree 4.2.0. Acceleration in the radeon driver has been much improved since the 4.2.0 release; I can't reproduce this problem with current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xfree CVS experience
On Don, 2002-12-05 at 20:15, Thomas Estaben wrote: > > On Thursday 05 December 2002 20:04, Thomas Estaben wrote: > > > > Primary, thanks a lot for your hard and very good job ;). > > > > Now my problem.. I tried recently (today) a xfree-cvs on a glibc 2.3.1/gcc > > 3.2.1 system. > > I own a ati radeon mobility m7 LW. > > I tried with and without dri. > > > > With dri, i have a blankscreen, and nothing appear in the screen, the box > > is locked, no keyboard so reset is the only way. I attached my > > XFree86.0.log-dri. Have you tried an AGP transfer rate lower than 4x? Anything above 1x tends to cause instabilities for little gain. Are you using the DRM built from XFree86 CVS or the one from the kernel? > > Without dri, X starts but i have a lot problem. > > First my keyboard seems to not respond to the Alt key, so > > ctrl+alt+backspace is impossible, nor alt+Fx... :o/ This has been discussed here recently and should be fixed now AFAIK. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 8500 + PowerPC = Yellowish tint
On Mon, 2002-11-25 at 18:02, David Brown wrote: > > I've managed to get XFree86 4.2.0 built and running on powerpc. Using > the ati driver, 'UseFBDev', and the radeonfb kernel driver, the best > display I can get is 640x480 with most of the display tinted yellow. > > Has this been reported yet? Is there anything I can do? Yes, you need a recent benh kernel. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ati radeon 8500, dri r200 snapshot driver, X crash -Caught signal 11???
On Sam, 2002-11-30 at 21:25, jozob wrote: > I have ATI RADEON 8500, 64 MB DDR."powered by ati". > Hi, i have installed the newest snapshot R200 dri drivers, You should report problems with these to one of the DRI lists. > i have also installed the extras. But when i start X, it shows screen and > cursor, but then immediately stops and shows me: [...] >*** If unresolved symbols were reported above, they might not >*** be the reason for the server aborting. > > Fatal server error: > Caught signal 11. Server aborting Just a guess: can you try without the freetype module? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Radeon 8500 + PowerPC = Yellowish Tint
On Don, 2002-11-28 at 15:44, David Brown wrote: > > I'm continuing to pound on the Radeon 8500 on PowerPC with very little > luck. The display is corrupted at all bit depths. I'm currently using > 2.4.20-rc3-ben0 per a previous suggestion; I've also tried -rc4 and > -rc1. This is with Debian's XFree86 4.2.1, the radeon driver, and > 'UseFBDev'. The fix is restricted to Radeon 9000 chips yet. In drivers/video/radeonfb.c, look for newmode.surface_cntl and enable the part where 0 is assigned to it. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Mon, 2002-11-25 at 04:39, Eric Anholt wrote: > On Sun, 2002-11-24 at 17:42, Michel Dänzer wrote: > > > > it locks up solid when I request a signal to be delivered. Now I'd very > > much like to get this into 4.3.0, so I'd appreciate someone pointing > > out the stupid mistake(s) I'm probably making. :) > > Thoughts on it so far: Is it legal to hijack the si_code field for this > use? Where would the timestamp go that was talked about? I don't know. :/ This is all very new for me... > Also, shouldn't you be using list_add/list_del for those list things done? That's a very good idea, in fact the problem lay there. In other words, it seems to work now! :) Updated patch at http://penguinppc.org/~daenzer/DRI/drm-vblank-signal.diff, only tested on r100. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]wierd xterm bug
On Mon, 2002-11-25 at 02:45, James H. Cloos Jr. wrote: > I'm not sure what causes this bug, whether it is in xterm, the x > server, icewm or elsewhere > > Occasionally my xterms get into a mode where mouse clicks no longer > act as expected. A left or right click, rather than raising and > focusing the window, selects all of the text in the xterm from the > beginning of the saved lines to the line where the click occured. > > Middle clicks continue to paste the selection. > > Once, choosing the Show Alternate Screen option and then unchoosing it > got the xterm back to normal, but that is not working either, just now. > > One possibly relevant issue is gettimeofday(). The box crashes > occasionaly (bad smm bios I think) and the rtc is always off by a few > hours on a reboot after such an event. (Ntpd keeps it w/in a few > centiseconds ordinarily; only the hard crashes fubar the rtc.) I have > pppd run ntpdate when it starts, so there is a significant jump > backward in time every once in a while. Might that cause the bug? Yes, this is a known problem in the X server which has been fixed in CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Off by one error in drawing code for Radeon VE
On Mon, 2002-11-25 at 02:57, Kevin E Martin wrote: > On Mon, Nov 25, 2002 at 12:02:32AM +0100, Michel Dänzer wrote: > > On Son, 2002-11-24 at 22:53, Kevin E Martin wrote: > > > On Sun, Nov 24, 2002 at 09:57:36PM +0100, Michel Dänzer wrote: > > > > On Don, 2002-11-21 at 06:44, Andrew P. Lentvorski wrote: > > > > > Okay, you wanted isolation; you got isolation. ;) > > > > > > > > > > The option which makes the problem go away is: > > > > > > > > > > Option "XaaNoDashedTwoPointLine" > > > > > > > > While this has been much improved in current CVS, Mark's linetest > > > > program still produces some artifacts. Kevin, have you gotten around to > > > > look into that yet? > > > > > > Yes. I rebuilt from the latest CVS tree, and ran xtest and Mark's > > > linetest program. It all worked fine for me -- i.e., no artifacts. > > > > > > The latest I've heard is that the person who had the problems and > > > rebuilt from CVS but didn't install the new XAA. They were going to try > > > installing the new XAA to see if that helps (or they could just build a > > > non-loadable server for testing). > > > > > > However, if Mark's linetest program produces artifacts for you, please > > > let me know the exact coordinates, the dash pattern used, and if end > > > caps are on/off, since I have not been able to reproduce this problem. > > > This info should be trivial to gather in the debugger. It might simply > > > be that there are specific dash patterns that cause problems that I have > > > not tested. Also, please let me know if this happens on big or little > > > endian machines, or both. > > > > I told you two months ago that I get artifacts both on my TiBook with a > > 7500 Mobility as well as on an Athlon box with a 7500. You said you > > thought you knew what the problem is. > > Yes, I remember that e-mail conversation, but I believe the problem you > pointed out two months ago is a different problem and is specific to > Radeon 7500 (RV200) and later cards. FYI, I think the solution to the > drawing errors on the 7500 and later cards is to properly set the > bres_cntl field in the dst_line_patcount register. Does that mean we could implement full-blown Bresenham lines with the newer chips? > However, the problem from the original e-mail in this thread was said to > be with a Radeon VE (see the subject line), which is older than the 7500 > and does not appear to have the bres_cntl field. As I mentioned above, > I've rebuilt from the latest CVS tree, and ran xtest and Mark's linetest > program. It all worked fine on my VE card. At this point, I'm not sure > what the problem with the VE is. I see, sorry for the confusion. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: But *why* no vblank?
On Mit, 2002-11-06 at 18:04, Keith Packard wrote: > Around 16 o'clock on Nov 6, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > Okay, is there anything wrong with turning the struct for the ioctl into > > a union of a request and a reply struct? :) > > That is the usual way, I believe... Or, you can just build a larger > struct containing both pieces. > > > Yes. The blocking ioctl also returns a timestamp, is that important for > > the signal? > > Might be nice; there's plenty of space. Is it expensive to compute? > > > Oh, and BTW, is it okay for the ioctl to trigger a single signal, or > > would it have to generate signals indefinitely? > > Might want a mode that chose between these two options, but if I had to > pick one, I'd ask for a single signal. That's what SYNC wants. http://penguinppc.org/~daenzer/DRI/radeon-vbl-signal.diff is an attempt at this, unfortunately not successful - it locks up solid when I request a signal to be delivered. Now I'd very much like to get this into 4.3.0, so I'd appreciate someone pointing out the stupid mistake(s) I'm probably making. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Off by one error in drawing code for Radeon VE
On Son, 2002-11-24 at 22:53, Kevin E Martin wrote: > On Sun, Nov 24, 2002 at 09:57:36PM +0100, Michel Dänzer wrote: > > On Don, 2002-11-21 at 06:44, Andrew P. Lentvorski wrote: > > > Okay, you wanted isolation; you got isolation. ;) > > > > > > The option which makes the problem go away is: > > > > > > Option "XaaNoDashedTwoPointLine" > > > > While this has been much improved in current CVS, Mark's linetest > > program still produces some artifacts. Kevin, have you gotten around to > > look into that yet? > > Yes. I rebuilt from the latest CVS tree, and ran xtest and Mark's > linetest program. It all worked fine for me -- i.e., no artifacts. > > The latest I've heard is that the person who had the problems and > rebuilt from CVS but didn't install the new XAA. They were going to try > installing the new XAA to see if that helps (or they could just build a > non-loadable server for testing). > > However, if Mark's linetest program produces artifacts for you, please > let me know the exact coordinates, the dash pattern used, and if end > caps are on/off, since I have not been able to reproduce this problem. > This info should be trivial to gather in the debugger. It might simply > be that there are specific dash patterns that cause problems that I have > not tested. Also, please let me know if this happens on big or little > endian machines, or both. I told you two months ago that I get artifacts both on my TiBook with a 7500 Mobility as well as on an Athlon box with a 7500. You said you thought you knew what the problem is. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Off by one error in drawing code for Radeon VE
On Don, 2002-11-21 at 06:44, Andrew P. Lentvorski wrote: > Okay, you wanted isolation; you got isolation. ;) > > The option which makes the problem go away is: > > Option "XaaNoDashedTwoPointLine" While this has been much improved in current CVS, Mark's linetest program still produces some artifacts. Kevin, have you gotten around to look into that yet? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Colormap issues with 24bpp on big-endian system
On Son, 2002-11-03 at 21:15, [EMAIL PROTECTED] wrote: > > I submitted a bug report to the xdvi team about problems with wrong > colors on my PowerBook G4 (PowerPC platform). After some testing Paul > Vojta suggested the below: > > > At this point I suspect a server bug. I've enclosed a test program, > > pmtest.c, with Makefile. When I run it on a Sun Ultra 5 (24 bpp, > > blackpixel 0, whitepixel 16777215, big-endian) it shows (correctly) > > a hollow box in the middle of the window. In black, with a white > > background. I suspect it'll show something different in your case. > > I also suspect that if you change GXand to GXcopy or ZPixmap to XYPixmap, > > then it might work correctly. > > > > Please let me know how it turns out. > > > > If it is in fact a server bug, you can send the test program to > > [EMAIL PROTECTED] (or their official bug address). > > > > --Paul Vojta, [EMAIL PROTECTED] > > I tried to program, and the results are shown in the 2 attached > screenshots, respectively using GXand and GXcopy. Using GXcopy there > does not seem to be a problem, but GXand produces yellow instead of > white. I have the same hardware AFAICT, and I can't reproduce the problem with current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] Radeon M9 cursor fix
On Fre, 2002-11-22 at 21:03, Mark Vojkovich wrote: > >Michel, note that Keith fixed a BigEndian client bug with ARGB > cursors the other day. SW cursor works now. Great. > If your HW cursor support worked with the broken cursors it probably > doesn't work anymore with the correct ones. Thanks for the heads up. It's not a problem either way as the patch I posted can easily be adapted for any byte order. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] Radeon M9 cursor fix
On Fre, 2002-11-22 at 16:36, George Staikos wrote: > On Friday November 22 2002 07:58, Michel Dänzer wrote: > > On Don, 2002-11-21 at 18:12, George Staikos wrote: > > >Attached is a patch to uncorrupt the mouse pointer on PowerPC based > > > laptops with Radeon M9 chipsets. I'm not sure if there are other chipsets > > > that need this or not as this is the only one I have, but it fixes things > > > for me. > > > > IMHO this makes ugly code (bit masks and shifts to compensate for the > > framebuffer aperture byte swapping...) even uglier. I'd prefer disabling > > that byte swapping (as is done in the radeon Xv code and I proposed for > > ARGB cursors), using another aperture or a surface. > >I agree, it is ugly. But do we know that all the different models will > work this way? I have no docs so I was working blind. If we disable byte swapping, it doesn't matter if the byte swapping actually works or not (as seems to be the case for you). > > Moreover, this is probably a bandaid for the real problem, which I > > suspect also causes the color problems people are experiencing with > > Radeon 9000s on big endian machines: the byte swapping doesn't seem to > > work as expected. > > I have a partial solution for this too. It seems like pixmaps were the > main things that were coming through with wrong colours, and doing a byte > swap in the setup code in radeon_driver.c fixes it, just as the comment says > it might. (I just adjusted the RGB masks and offsets) However that breaks > non-pixmap writes. I'm sure someone out there knows exactly why this is, but > I haven't had any more time to work on it. I don't quite understand, can you post a patch for these changes as well? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cirrus on powerpc
On Fre, 2002-11-08 at 16:08, Marc Dietrich wrote: > > > On Mon, 2002-10-21 at 18:33, Marc Dietrich wrote: > >> > >> I have a cirrus gd5446 with 1 mb memory installed in a Motorola > >> Powerstack 4400 (PCI PPC) running linux (kernel 2.4.17pre1, suse 7.3). I > >> think the cirrus driver is not endian save, because it crashes my system > >> hard. I can't even get the framebuffer driver to work. > > > >What's the problem with the fbdev driver? > > > > When I try to start XFree86 with the framebuffer driver, the screen becomes > black and nothing is drawed, but the desktop gets loaded and I can kill it > "blind". Sadly, the text console becomes also black and no text is shown > anymore. Sounds like a problem with the mode it's using or a bug in the framebuffer device. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert][PATCH] Radeon M9 cursor fix
On Don, 2002-11-21 at 18:12, George Staikos wrote: >Attached is a patch to uncorrupt the mouse pointer on PowerPC based > laptops with Radeon M9 chipsets. I'm not sure if there are other chipsets > that need this or not as this is the only one I have, but it fixes things > for me. IMHO this makes ugly code (bit masks and shifts to compensate for the framebuffer aperture byte swapping...) even uglier. I'd prefer disabling that byte swapping (as is done in the radeon Xv code and I proposed for ARGB cursors), using another aperture or a surface. Moreover, this is probably a bandaid for the real problem, which I suspect also causes the color problems people are experiencing with Radeon 9000s on big endian machines: the byte swapping doesn't seem to work as expected. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Off by one error in drawing code for Radeon VE
On Mit, 2002-11-20 at 04:00, Andrew P. Lentvorski wrote: > I have a Radeon VE and was having problems with the dragging. Most > notably, dragging elements in Matlab left lots of junk on the screen. A > refresh would clear it, but it would just come back when I started doing > more stuff. > > So, I grabbed the latest version from CVS and recompiled. It's still > there. > > I also grabbed some code that I used to hunt down the clipping bugs for > this card the last time, it appears that there is an off-by-one error > somewhere as a slow drag leaves *lots* of junk on the screen while a fast > drag leaves junk at specific points. It feels like its non-rectangle (or > multiple rectangle) clipping related since Matlab uses wierd shaped > outlines to redraw the objects. > > If I need to run some tests or send a picture, let me know. Screenshots might be interesting, but isolating the affected acceleration primitive(s) would be most useful. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X locks up the complete system
On Die, 2002-11-19 at 09:24, Thomas Winischhofer wrote: > Michel Dänzer wrote: > > I can't give a definite answer but only an educated guess: with the HW > > cursor, Silken mouse may also be used, meaning that the cursor position > > is updated asynchronously, which may trigger a race condition in the > > driver. If this hypothesis is correct, the HW cursor shouldn't lock up > > if you start the server with the -nosilk option. > > What sort of race condition are you thinking of? The HWCursor code in > the driver does no wait's or anything, it just sets a few registers in > the MMIO area. I suspect that may exactly be the problem. It may interfere with other MMIO register access, overflowing the chip's FIFO or similar. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X locks up the complete system
On Sam, 2002-11-16 at 14:45, Igor Filippov wrote: > Here are my two cents: > > Linux 7.1 on > 1.3 GHz Athlon > ECS K7S5A Motherboard > 1024 mb ram > Matrox G450 > > I have been experiencing the exact same lockups. I have upgraded the kernel > to 2.4.19 and installed the XFree4.2 from the sources. Everything was > recompiled for athlon. Everything seemed ok for a while, but then it locked > up again just yesterday when I was logging in. Right after the xdm login > screen disappeared, but before the desktop had a chance to appear... The > root partition ended up being badly damaged, I am assuming as a result of > the hard reset. The lockup must've happened at some critical point? > > Actually, I did noticed that usually there is a whole lot more filesystem > damage in the result of the X lockup than, for example, when the computer > goes off because of a power blackout. It happened to me several times (I > don't have the UPS). In fact, there is this one error that I only get after > the lockup. I can't remember exactly what it says, but it's something along > the lines that several files (not links to files) end up pointing at the > same cluster on the hard drive, so it asks if I want to duplicate the > cluster. Those would usually be the files that I had open at the time of > lockup... I doubt X in particular but rather system load in general influences the severity of a crash. If you don't use a journalling filesystem already, that might be a good idea. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]X locks up the complete system
On Son, 2002-11-17 at 23:41, Mukhben Singh wrote: > Thanks to all of you for listening and helping. Now since all > seems to be well, I would be interested to know, why my machine locks up > with hardware cursor. I can't give a definite answer but only an educated guess: with the HW cursor, Silken mouse may also be used, meaning that the cursor position is updated asynchronously, which may trigger a race condition in the driver. If this hypothesis is correct, the HW cursor shouldn't lock up if you start the server with the -nosilk option. > Also performance wise I am not experiencing any issues with soft cursor. > Can anyone of you shed some light on the pitfalls or advantages of running > a sw cursor??? The hardware cursor is smoother (especially with Silken mouse) and less flickery in general, and there are cases where the software cursor simply doesn't work correctly (see the recent discussion here about ARGB cursors). -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cvs causes spontaneous reboot??
On Sam, 2002-11-16 at 14:26, Geoffrey wrote: > Downloaded cvs last night and built it successfully. Upon execution of > startx, screen goes blank, then I see the bios, spontaneous reboot. > > Running kernel 2.4.19 (not a stock Mandrake kernel), Mandrake 9.0, > Radeon VE 32mb agp vid card, secondary ATI Rage pci vid card. > > Athlon 1800+ xp processor 256 mb pc133 memory. > > At this point, the config file which was working fine with the previous > gatos drivers and Mandrake 9.0 drivers is configured for single head > Radeon, although my ultimate goal is to get a secondary head for the > Radeon or the Rage working. > > There was a log file generated which normal at first, but then appears > to have some kind of source code??? The file probably got corrupted due to the crash? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Linux input nightmare.
On Mon, 2002-11-11 at 10:08, Zephaniah E. Hull wrote: > The current state of affairs as far as being able to use > /dev/input/event directly is, exceedingly suboptimal. > > To be blunt, under 2.4.x kernels the interface lacks ANY way to > determine which device you have if you have two identical devices. > > To make matters worse, while there /are/ ioctls to get the bus location > for 2.5.x kernels the #defines do not even exist for the 2.4.x headers. #defines aren't a problem, just have a private header with everything you need. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]AdjustFrame in XFree86-drivers
On Son, 2002-11-10 at 19:42, Kral Stefan wrote: > > At the moment, some XFree86-drivers force synchronization with > the vertical retrace of the CRT whenever AdjustFrame is called, > whereas some drivers do not. > > I think that a uniform behaviour would be favorable. > > Tests have shown that the modifications necessary are trivial > and that the modified drivers work properly and reliably. > (Different people I know already tested that.) Have you tested the radeon driver with page flipping? I see a conflict there, page flipping requires updates to the CRTC offset to take effect immediately. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Alpha cursors broken on big endian
On Fre, 2002-11-08 at 22:24, Mark Vojkovich wrote: > On 8 Nov 2002, Michel Dänzer wrote: > > > On Fre, 2002-11-08 at 21:53, Mark Vojkovich wrote: > > > On Fri, 8 Nov 2002, Mark Vojkovich wrote: > > > > > > >Running top-of-tree on Linux PPC I'm finding that alpha blended > > > > SW cursors do not seem to work at all. All cursors appear blank. > > > > > > > > > >Actually depending on the color I do sometimes see stuff. The > > > gumby cursor ends up being lavender. Also, the data passed for > > > the HW alpha cursor isn't correct either. > > > > It's easy to make the radeon driver work with it, didn't you see the > > patch I posted? > > > >What did you patch? The SOFTWARE cursor is broken and it doesn't > have anything to do with the drivers. Subsequently, the data passed to > the driver for the HW interface is also incorrect. I don't follow. The fact that the software cursor is broken doesn't imply that the data is incorrect (is its endianness defined?) - it might be the blending code treating it incorrectly. > If you've patched your driver to work with this incorrect data, that > was the wrong solution to the problem. Maybe. It shows how the driver can basically handle any data. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Alpha cursors broken on big endian
On Fre, 2002-11-08 at 21:53, Mark Vojkovich wrote: > On Fri, 8 Nov 2002, Mark Vojkovich wrote: > > >Running top-of-tree on Linux PPC I'm finding that alpha blended > > SW cursors do not seem to work at all. All cursors appear blank. > > > >Actually depending on the color I do sometimes see stuff. The > gumby cursor ends up being lavender. Also, the data passed for > the HW alpha cursor isn't correct either. It's easy to make the radeon driver work with it, didn't you see the patch I posted? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]change input device on the fly?
On Don, 2002-11-07 at 17:47, Adam Luter wrote: > Not an expert, but have you tried to specify both devices at the same > time? You may still have to restart X, Not if you use /dev/input/mice for the USB mouse. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Mit, 2002-11-06 at 17:39, Billy Biggs wrote: > Michel Dänzer ([EMAIL PROTECTED]): > > > > It would be preferable in general for video apps, though, to provide > > > a DRM-based api to use the overlay buffer, too. Like, a DRM-Xv. > > > For desktop use, the X11 context switch may be fairly acceptable > > > with something like XSYNC, but to achieve really excellent quality > > > (eg, suitable for output to a TV/broadcast/etc.) in, say, a video > > > player, a direct API would be nicer. > > > > If I'm not mistaken that's what XvMC is for. > > No, XvMC is an API to hardware motion compensation, basically for > hardware MPEG decoding. Don't let the name mislead you. Sure, motion compensation was probably the initial motivation, but my understanding from reading posts about it on Xpert (Mark or someone please correct me if I'm wrong) is that it supports non-MC surfaces, so it's basically a beefed up Xv which supports MC and direct rendering. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon VE w/ dual monitors not loading
On Mit, 2002-11-06 at 05:37, Ryan Oertel wrote: > I've seen this posted many times to this list, so I know it's not an uncommon > problem, I've scoured the mailing lists and google's groups for anything, > but none of the configuration files and tips seem to work for me. > > I'm trying to get two monitors working in X with my Radeon VE card. When I > start X, both monitors go to sleep. I can CTRL+ALT+F6 to bring them back. > "Screen 0" is connected to the digital port and "Screen 0" to the analog. > Here's the system setup: > > -RedHat 7.2 (with updates from updates.redhat.com) > -XFree86 4.1.0-25 (from rpms) > > I have been working at this on and off for several days with little progress. > Attached, are copies of my XF86Config-4 and XFree86.0.log. Look fine to me; you may need the driver from current CVS, I think that's the case for OEM cards in particular. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Mit, 2002-11-06 at 18:04, Keith Packard wrote: > > Around 16 o'clock on Nov 6, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > Yes. The blocking ioctl also returns a timestamp, is that important for > > the signal? > > Might be nice; there's plenty of space. Is it expensive to compute? Nah, do_gettimeofday(). Currently done on ioctl exit, but would probably better be done in the interrupt handler, assuming that's possible. > > Oh, and BTW, is it okay for the ioctl to trigger a single signal, or > > would it have to generate signals indefinitely? > > Might want a mode that chose between these two options, but if I had to > pick one, I'd ask for a single signal. That's what SYNC wants. Very well, I'll leave it at that then. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Son, 2002-11-03 at 23:46, Elladan wrote: > On Sun, Nov 03, 2002 at 03:00:53PM +0100, Michel D?nzer wrote: > > On Son, 2002-11-03 at 06:17, Elladan wrote: > > > > > > It might be best to provide both interfaces. It's probably not > > > significantly harder to provide both API's - they both trigger off the > > > same hardware event. > > > > Yes, I'm looking into adding a flag to the ioctl so it sends a signal > > instead of blocking. Shouln't be too hard, but I haven't found out yet > > whether a signal can be delivered from an interrupt top half, if anyone > > knows I'd appreciate letting me know before I find out the hard way. :) [...] > And no, I don't think a signal can possibly be delivered in the top > half, by the way. It's going to get delayed by the userspace transition > just as much as a blocking system call would (probably more), so mostly > I think it's just a tool for single-threaded apps to handle vblanks. I Yeah, I didn't mean that but simply whether a top half can call something like deliver_signal() and then the signal gets delivered the next time the process is scheduled. But maybe it's better to use a bottom half anyway. I think most of the other points you raise would probably better be handled by driver specific extensions but are most definitely beyond the scope of what we're trying to achieve here. > It would be preferable in general for video apps, though, to provide a > DRM-based api to use the overlay buffer, too. Like, a DRM-Xv. For > desktop use, the X11 context switch may be fairly acceptable with > something like XSYNC, but to achieve really excellent quality (eg, > suitable for output to a TV/broadcast/etc.) in, say, a video player, a > direct API would be nicer. If I'm not mistaken that's what XvMC is for. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Son, 2002-11-03 at 18:47, Keith Packard wrote: > > Around 15 o'clock on Nov 3, Michel =?ISO-8859-1?Q?D=E4nzer?= wrote: > > > Oh, and are there any opinions about the signal to use, SIGALRM or > > something else? > > You'll have to make it settable -- SIGALRM is already used by the X server > for scheduling. Of course, we could eliminate that if I could get the > current time of day mapped into the X server address space :-) Okay, is there anything wrong with turning the struct for the ioctl into a union of a request and a reply struct? :) > > > * The interface needs to provide a vblank counter, so the user can easily > > > detect dropped vblanks. > > > > Has been there from day 1. I wonder what to do about this for the signal > > though, put the sequence number into the siginfo (is that possible?), or > > is the information you get back from the ioctl enough? > > It would be nice to get it without another syscall; there's certainly > enough space in the siginfo to pass it along. I assume you'd pass along > the current counter value and not some kind of delta. Yes. The blocking ioctl also returns a timestamp, is that important for the signal? Oh, and BTW, is it okay for the ioctl to trigger a single signal, or would it have to generate signals indefinitely? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI r128 and documentation
On Die, 2002-11-05 at 09:53, Aymeric Vincent wrote: > > Michel Dänzer <[EMAIL PROTECTED]> writes: > > > On Son, 2002-11-03 at 17:03, Aymeric Vincent wrote: > > > > > > Actually, I would like to understand how the r128 chip reads the video > > > memory and sends it to the CRTC, because when I use 15/16 or 24 bit > > > modes, the display on the CRT monitor (through CRTC2) is split > > > horizontally in two/two or four respectively, and the same half or > > > quarter left-hand side of the screen is repeated on the right. The > > > Flat Panel driven by the first CRTC is OK. Does such a behaviour ring > > > a bell? > > > > The columns are okay? > > Yes. I get two or four copies of the first stripe. > > Although some vertical lines in the first copy are shifted by one > pixel to the bottom. But the displayed image is stable. > > > > [ My interpretation is that the CRTCs have a small buffer that can > > > contain a certain amount of pixels (obviously depending on the number > > > of bytes per pixel), and if for whatever reason the video memory can't > > > keep up, they will redisplay what is available in their buffer until > > > the next line. ] > > > > That's not my understanding, for what that's worth. (Why would the video RAM > > not be able to keep up, anyway? Keep up with what?) The colors are okay, > > i.e. it's not displaying 8 bit data in another depth? > > Everything is okay from this point of view. I was thinking that > enabling the second CRTC could imply using twice the bandwidth, since > both CRTC could be displaying different parts of the video RAM. True, but I don't think bandwidth starvation would cause a repeated image; I may be wrong though, but I suspect you aren't programming the registers quite correctly yet. > To be precise, in order to get sensible values from the registers (as > set up by the OpenFirmWare of my iBook), I need the following patch: > > --- r128_reg.h2002/09/04 15:10:14 1.1.1.5 > +++ r128_reg.h2002/10/14 09:05:21 > @@ -554,8 +559,8 @@ > #define R128_FOG_3D_TABLE_DENSITY 0x181c > #define R128_FOG_TABLE_INDEX 0x1a14 > #define R128_FOG_TABLE_DATA 0x1a18 > -#define R128_FP_CRTC_H_TOTAL_DISP 0x0250 > -#define R128_FP_CRTC_V_TOTAL_DISP 0x0254 > +#define R128_FP_CRTC_H_TOTAL_DISP 0x0254 > +#define R128_FP_CRTC_V_TOTAL_DISP 0x0258 > #define R128_FP_GEN_CNTL 0x0284 > # define R128_FP_FPON (1 << 0) > # define R128_FP_BLANK_DIS (1 << 1) I just downloaded the M3 register reference, and it says 0x250/0x254. 0x258 would be CRT_CRTC_H_SYNC_STRT_WID . -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: No DRI for Dual-headed setup?
On Son, 2002-11-03 at 21:05, Kacper Wysocki wrote: > > > Fortunately, I can't do that comparison here, but it's pretty fast, > > even > > with a window that covers the whole screen. Does the lack of perfect > > smoothness bother you? Note that the window manager can make a huge > > difference there, e.g. sawfish was much worse than metacity here. > Perfection has always been my demand. I use openbox; I've tried other > wm's, including metacity, and I get the same results. still, I'd expect > smooth window refresh from such a hefty peice of software as XF86..? > I've seen quite a number of other people complain about this as well. Yes, it comes up over and over, the bottom line is that it's not as easy as those people think it is. > In fact, a friend of mine who owns an older radeon says he's got great > 3d accel but no 2d accel, The radeon driver had limited 2D acceleration with DRI enabled up to 4.2.0. This has been remedied in CVS, it now offers even faster 2D acceleration on top of the 3D acceleration. > and wishes for a window manager that uses pure glx. Sounds like he wants e17. > the lack of dri in dualhead and the fact that you have to restart X to > change the dualhead setup seriously hampers things, as you can imagine. Would running two servers be an option for you, one with DRI enabled and the other with dualhead? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Separate Build Tree
On Die, 2002-11-05 at 03:03, [EMAIL PROTECTED] wrote: > > [~/sources]$ mkdir build > [~/sources]$ cd build > [~/sources/build]$ lndir -silent -ignorelinks ../xc > [~/sources/build]$ make -C ../xc World Unless I'm missing something, you aren't using the build directory at all then. What happens if you just make World? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI r128 and documentation
On Son, 2002-11-03 at 17:03, Aymeric Vincent wrote: > > Michel Dänzer <[EMAIL PROTECTED]> writes: > > > It's also my impression that dualhead support shouldn't be hard to add > > looking at the radeon driver. In fact, it might be doable without docs, > > someone even posted a quick'n'dirty but untested patch here. If you > > absolutely need to consult documentation for something, I'll gladly look > > it up. And once you've achieved something, ATI might be less hesitant to > > provide the docs to you. > > Actually, I would like to understand how the r128 chip reads the video > memory and sends it to the CRTC, because when I use 15/16 or 24 bit > modes, the display on the CRT monitor (through CRTC2) is split > horizontally in two/two or four respectively, and the same half or > quarter left-hand side of the screen is repeated on the right. The > Flat Panel driven by the first CRTC is OK. Does such a behaviour ring > a bell? The columns are okay? > [ My interpretation is that the CRTCs have a small buffer that can > contain a certain amount of pixels (obviously depending on the number > of bytes per pixel), and if for whatever reason the video memory can't > keep up, they will redisplay what is available in their buffer until > the next line. ] That's not my understanding, for what that's worth. (Why would the video RAM not be able to keep up, anyway? Keep up with what?) The colors are okay, i.e. it's not displaying 8 bit data in another depth? > If I understand correctly, you have access to the ATI documentation, > and although I may be wrong, it looks from experimental values I get, > that in xc/programs/Xserver/hw/xfree86/drivers/ati/r128_reg.h, the > offsets of R128_FP_CRTC_H_TOTAL_DISP and R128_FP_CRTC_V_TOTAL_DISP are > shifted by 4 bytes, from 0x0254/0x0258 to 0x0250/0x0254. I suspect the > same shift occurs for the radeon. Could you please confirm this? Depends how you think they're shifted. ;) For the Radeon, the docs I have say 0x250/0x254; the Rage128 docs I have don't cover these registers, but I guess they may well be the same. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 gdb for Linux PPC?
On Mon, 2002-11-04 at 02:56, Mark Vojkovich wrote: >Is there an XFree86 module-aware version of gdb for Linux PPC > someplace? I'm not aware of any binaries, but the patch for current gdb versions is mostly architecture independent. I hope Mike will manage to get it integrated into stock gdb soon... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI r128 and documentation
On Die, 2002-10-29 at 14:27, Aymeric Vincent wrote: > > I have an iBook with a r128 LF. The video output in mirroring mode is > broken (recognizable but waves horizontally). I could manage to make > it work in 256 colours by switching to using the second CRTC (and > feeding it with the right values), but I failed to make it work in > 15/16/24 bit modes. > > I contacted ATI in order to get documentation, so that I could improve > the situation and also prepare some patch that wouldn't break other > cards which may not have a second CRTC (?). However I got no reply so > far. Can anyone on this list help me, at least get in touch with them? > I am willing to sign an NDA if need be. > > >From what I saw, it looks like the R128 LF is much like a radeon chip > as far as dual-head is concerned: it looks like it should be easy to > add Xinerama support to the r128 driver. The registers for the second > hardware cursor do exist and work, the two different offset registers > work as expected, etc. It's also my impression that dualhead support shouldn't be hard to add looking at the radeon driver. In fact, it might be doable without docs, someone even posted a quick'n'dirty but untested patch here. If you absolutely need to consult documentation for something, I'll gladly look it up. And once you've achieved something, ATI might be less hesitant to provide the docs to you. There still seem to be quite a lot of Rage128 users who'd certainly appreciate your work! -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]No DRI for Dual-headed setup?
[ First off, it's better to post to a DRI list about the DRI ] On Son, 2002-11-03 at 06:06, Kacper Wysocki wrote: > I've finally gotten what I want (within XF86's limitations) for my X, > namely > -radeon accel working(windows are still horribly sluggish-try it and > see: grab a window by its bar and shake it. Repeat on > well-configured(yeah right) winblows with same gfx card. You see what I > mean?) Fortunately, I can't do that comparison here, but it's pretty fast, even with a window that covers the whole screen. Does the lack of perfect smoothness bother you? Note that the window manager can make a huge difference there, e.g. sawfish was much worse than metacity here. > -dual headed, no xinerama (better than bug-eyed xinerama) > -xv working > -dri working (Only in 16bit, one-headed and while root) > > All this by building from CVS, with the help of one Andrew > Atrens(thanks!) > > But of course I'm not satisfied with this: > > > (WW) RADEON(0): Direct Rendering Disabled -- Dual-head > configuration > > is not working with DRI at present. > > Please use only one Device/Screen section in your XFConfig file. [...] > Now my question is: if there's a problem in Xinerama, and I don't run > xinerama, can I safely enable this? If it was that simple, it wouldn't have been disabled in the first place... > Or does "dual-head configuration" include dualheaded setups that don't > run xinerama? It does say 'dualhead', not 'Xinerama', for a reason. The 3D driver has absolutely no notion of a shared entity yet. What should work would be implementing dualhead with a single framebuffer on top of the CloneDisplay support in current CVS. > Why is drm access restricted to root, and how do I go about changing > it? Simple /dev/dri permissions issue here(I modified this, but can't > check it right now)? Probably, see http://www.xfree86.org/current/DRI6.html#10 > And what gives with the 16bit(and 32bit, haven't checked) only support? Radeons can only render 3D primitives in depth 16 and depth 24, fbbpp 32. Depending on the desktop resolution and the available video RAM, the DRI may only be enabled in depth 16. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: But *why* no vblank?
On Son, 2002-11-03 at 06:17, Elladan wrote: > On Fri, Nov 01, 2002 at 02:30:29PM -0800, [EMAIL PROTECTED] wrote: > > > Sender: [EMAIL PROTECTED] > > > On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: > > > > Yes, XSYNC has the right things to allow applications to synchronize > > > > on arbitrary things (including vertical sync). > > > > > > > > If the fbdev and/or DRI folks are willing to support and export an > > > > interface, it should be possible to get the plumbing hooked up. > > > > > > > > Just make it a file descriptor we (and/or other things) can select against, > > > > and it should be something that can be pretty cross platform without much > > > > trouble: them's that don't implement it on a given platform won't get > > > > support... > > > > > > The interface we've implemented in the DRM is an ioctl which basically > > > blocks for a requested number of vertical blanks (it's more flexible in > > > fact). Maybe a daemon or something could provide a file descriptor to > > > select against? > > > > I've just chatted with Keith Packard on this. > > > > This interface (an ioctl that blocks) isn't a good one. > > > > How about a signal when vertical blanking arrives? (1st choice) That, or > > something we can select on? (2nd choice) > > It might be best to provide both interfaces. It's probably not > significantly harder to provide both API's - they both trigger off the > same hardware event. Yes, I'm looking into adding a flag to the ioctl so it sends a signal instead of blocking. Shouln't be too hard, but I haven't found out yet whether a signal can be delivered from an interrupt top half, if anyone knows I'd appreciate letting me know before I find out the hard way. :) Oh, and are there any opinions about the signal to use, SIGALRM or something else? > Some things to consider: > > Very nice: > > * The interface needs to provide a vblank counter, so the user can easily > detect dropped vblanks. Has been there from day 1. I wonder what to do about this for the signal though, put the sequence number into the siginfo (is that possible?), or is the information you get back from the ioctl enough? The ioctl also provides a timestamp, but that's pretty arcane yet, so people who intend to use that please look at it and help improve it if necessary (hint, hint, Billy Biggs :). > * It would be nice to provide a way to get either the start of the > vertical blanking period, or end end of it (or both). The start is > most important, of course. Only the start is supported so far. > Nice but not as important: > * It would be nice if the interface provided a way to request the > current scan line, and block on particular scan lines. Hardware which > didn't support this (eg., LCD monitors, less-good video cards, etc.) > would of course be expected to return an error. What would that be useful for? As you've explained very well in your other post, the various latencies don't allow for such fine grained timing. > * It would be nice if the interface provided a way to latch particular > simple actions, such as a buffer flip, to the interrupt directly. For > example, with an ioctl: > > vbc.action = VB_SWAP_BUFFERS; > vbc.arg1 = BUFFER1_TOKEN; > vbc.arg2 = BUFFER2_TOKEN; > > ioctl(vblankdev, WAIT_FOR_VBLANK_AND_DO_SOMETHING, &vbc); > > Here, the ioctl blocks until the vblank, and the driver performs the > command in the interrupt handler if possible. Not sure about this. I've played with doing this for flips in the radeon 3D driver, and it didn't work out all that well. Granted, I didn't do the flip in the interrupt top half, but I'm not sure if that's feasible. > Remember, what people need isn't *only* a way to avoid tearing by > syncing on the vblank. They also need a way to schedule output onto the > vblank intelligently. For example, a video player needs some way of > determining what the refresh rate is, so it can select a scheduling > strategy for its output. I think that should be possible with what we have? IIRC all the drivers that support this ioctl also support XVideo double buffering synced to vertical refresh, so if you do the XvPutImage immediately after you get notified about a vertical blank, you can be pretty sure it'll be displayed on the next one. And you can deduce the refresh rate from the timestamps. PS: A: No. Q: Should I include quotations after my reply? ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fre, 2002-11-01 at 21:10, [EMAIL PROTECTED] wrote: > Yes, XSYNC has the right things to allow applications to synchronize > on arbitrary things (including vertical sync). > > If the fbdev and/or DRI folks are willing to support and export an interface, > it should be possible to get the plumbing hooked up. > > Just make it a file descriptor we (and/or other things) can select against, > and it should be something that can be pretty cross platform without much > trouble: them's that don't implement it on a given platform won't get > support... The interface we've implemented in the DRM is an ioctl which basically blocks for a requested number of vertical blanks (it's more flexible in fact). Maybe a daemon or something could provide a file descriptor to select against? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]But *why* no vblank?
On Fre, 2002-11-01 at 19:42, Billy Biggs wrote: > > Some folks in the DRI world are doing a standard device API. There > are also a million different kernel module hacks that export vsync > interrupts existing now, look at any of the video applications right > now: we have like 4 different mga kernel modules for hardware overlay > surfaces with vsync interrupts, now svgalib has their own kernel > callback driver, DRI has theirs presumably for page flipping at some > point, etc. I think it might be a good idea to write a small abstraction library which can use the various means (DRM, svgalib, ...) that already provide this. > I think the main reason for the lack of a standard effort is the > varying requirements of the projects proposing these solutions. The > mplayer folks (and some xine/etc authors) want some kernel solution > that's independent of X and DRI and fbcon, since they want to support > different levels of exlusive or direct access. Some other projects, > such as DirectFB, only care about this in the context of fbcon itself. > And then the DRI folks only care about X, and so solutions from that > arena may not work outside of a running X server. As you can see in http://dri.sourceforge.net/IRC-logs/20020121.txt (and/or maybe some following logs), it is a long term goal of the DRI project to support other environments, but so far I'm not aware of any real effort from outside the project except maybe fbdri. You don't absolutely need an X server to use the DRM, although you probably need to act pretty much like an X server at this point. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xinerama + Radeon = No error + No Worky
On Fre, 2002-11-01 at 16:02, Adam Luter wrote: > On Thu, Oct 31, 2002 at 03:22:27PM -0600, Adam Luter wrote: > > Attached are my XF86Config-4 and XFree86.0.log files. I believe I > > have correctly setup my XF86Config-4 file, however my second monitor > > does not receive any signal.> > > This time I promise not to forget to attach the files! Sorry :) Your config looks fine to me, and the log looks similar to the one someone else posted recently, i.e. everything looks fine except the driver doesn't mention the second head at all. As I said in that other thread after looking at the source, the driver seems to ignore the second head under some circumstances I don't understand; maybe Hui Yu or Kevin E. Martin would. There's also a good chance for this to work better in current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Backing store on Radeon?
On Don, 2002-10-31 at 18:38, Alan Hourihane wrote: > On Thu, Oct 31, 2002 at 01:30:32 +0100, Michel Dänzer wrote: > > On Mit, 2002-10-30 at 17:02, Alan Hourihane wrote: > > > On Mon, Oct 21, 2002 at 09:16:35 -0700, Ian Romanick wrote: > > > > 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. > > > > > > This looks like the XAA acceleration is to blame. > > > > > > If you add > > > > > > Option "XaaNoCPUToScreenColorExpandFill" > > > > > > Then you get most of the text back, except for the menu bar. It seems > > > that this function isn't honouring transparency information. So we could > > > add NO_TRANSPARENCY to this or find out why it's not working right. > > > > I don't see how transparency comes into play with ColorExpandFill, > > unless maybe transparency is accidentally enabled from a previous > > operation? Or is it not using the background color? > > Exactly, transparency meaning just the foreground color is used, and > by setting NO_TRANSPARENCY int the CPUTopScreen flags it makes XAA never > send the chip a background color of -1. I still don't understand: if that's broken, how does all the text I'm seeing work? Is that all rendered with a background color? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 7000 Dual head not working
On Don, 2002-10-31 at 00:53, Keith Folske wrote: > I am trying to get my Radeon 7000 working with two monitors. The message at > the end of the log says: > > == > Symbol drmScatterGatherFree from module > /usr/X11R6/lib/modules/drivers/radeon_drv.o is unresolved! > Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is > unresolved! > Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is > unresolved! > Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is > unresolved! > Symbol drmUnmap from module /usr/X11R6/lib/modules/drivers/radeon_drv.o is > unresolved! > > Fatal server error: > Caught signal 11. Server aborting > > > When reporting a problem related to a server crash, please send > the full server output, not just the last messages. > This can be found in the log file "/var/log/XFree86.0.log". > Please report problems to [EMAIL PROTECTED] > > (II) Screen 0 shares mem & io resources > (II) Screen 1 shares mem & io resources > (II) RADEON(0): Shutting down Xvideo subsystems Let me guess, Mandrake? Or GATOS? Either way, people who experienced this problem reported that stock XFree86 4.2.[01] works. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] Backing store on Radeon?
On Mit, 2002-10-30 at 17:02, Alan Hourihane wrote: > On Mon, Oct 21, 2002 at 09:16:35 -0700, Ian Romanick wrote: > > 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. > > This looks like the XAA acceleration is to blame. > > If you add > > Option "XaaNoCPUToScreenColorExpandFill" > > Then you get most of the text back, except for the menu bar. It seems > that this function isn't honouring transparency information. So we could > add NO_TRANSPARENCY to this or find out why it's not working right. I don't see how transparency comes into play with ColorExpandFill, unless maybe transparency is accidentally enabled from a previous operation? Or is it not using the background color? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 9700 Pro
On Die, 2002-10-29 at 12:53, Stian Jordet wrote: > > Will there ever be support for Radeon 9700 Pro in XFree? I would be very > happy with just 2d support. 2D support is in current CVS and will be in 4.3.0. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Laptop Alternate Display Using CRT
On Sam, 2002-10-26 at 11:03, Simone Marzona wrote: > > I got a toshiba laptop and obviously I got the same problem when attach > an external crt display. > > Do not try to create different video modes and use the same > modelines/settings for lcd/crt... you could damage it... > > The solution I found is this: > > -create two version of XF86config > -one is the default used in the runlevel 5 (the one for lcd) > -the other is for external crt monitor. > -edit manually (or even with sax2 on suse..) and add "crt_screen" option > to force X to use the external monitor. > > I manage the two configurations as this: > > -the one for lcd is the default used from X when I start the system > -the one for crt is used when I boot to runlevel 3 and do a startx -- > -xf86config XF86Config.crt > > It's not very nice... But I can't find a way for choosing from gdm what > configuration to use (because X is already running...I think)... perhaps > making a new runlevel which is identical of the fifth except that X uses > a specified config file... and so at boot time you can choose... it > could be a nicer solution... You can have gdm start several X servers, one for each config file or layout section or whatever. But you might even get away with a single server if you set it up for true dualhead with overlapping screens. The cursor will only be on one head then though, if you need it on both you may want to try the CloneMode feature from current CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Doublehead radeon 7500 problem
On Son, 2002-10-27 at 15:31, Ivan Mitev wrote: > > i saw some other related posts related to doubleheaded 7500, but > unfortunately, they didn't help me much setting it up > > i have a gigabyte AR64DG card with radeon 7500 chipset, with gigabyte mb > with via KT266 chipset, and athlon XP 1600+; lnx distro is redhat 7.3 > > i 1st tried with the std XFree install from redhat 7.3 (4.2.0-8 rpms), > then with the stock 4.2.0 tarballs from xfree.org ftp, and then with 4.2.1 > update, but still with no luck > > it seems that the chipset is detected ok, but when i compare my logfile to > the one of the post "Radeon 7500 dual head problems" (Tue, 3 Sep 2002 > 08:59:49 -0400), i don't get any RADEON(1) info. i tried lots of > combinations of config files (with/without xinerama, different > options,...) [...] > Section "Screen" > Identifier "Screen0" > Device "Card0" > Monitor"Monitor0" > DefaultDepth 16 > SubSection "Display" > Depth 16 > Modes "1280x1024" > EndSubSection > EndSection > > Section "Screen" > Identifier "Screen1" > Device "Card1" > Monitor"Monitor1" > SubSection "Display" > Depth 16 > Modes "1280x1024" > EndSubSection > EndSection I can't offer much more than a shot in the dark, but does it make a difference if you also put DefaultDepth 16 in the screen section for "Screen1"? What kind of displays do you have connected to what ports? It seems that the driver ignores the secondary port under some circumstances, but I don't really understand that part of the code. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Author/maintainer for R128 driver?
On Sam, 2002-10-26 at 10:34, Dr Andrew C Aitchison wrote: > On Fri, 25 Oct 2002, Marc MERLIN wrote: > > > Ok, so no one seems to know about my XV problem with the R128 driver. > > Does anyone know who the current maintainer(s) is/are? > > cvs log xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c includes > > revision 1.62 > date: 2002/06/04 23:04:50; author: dawes; state: Exp; lines: +3 -1 > 180. ... > 179. ... > 178. Add an option to the r128 driver for enabling DMA for Xv image transfers > (#5195, Michel Dänzer). I was probably one of the last people working actively on the r128 driver, but I no longer have any Rage128 hardware. I think Kevin E. Martin maintains the driver. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]apple cinema + radeon dvi
On Fre, 2002-10-25 at 13:43, Colin Law wrote: > > I've just put together a new system with an 23" apple cinema hd display > using an ati radeon 7500 card through the apple adc to dvi convertor. > However i get nothing on the display after power up. The power light on > the apple appears to comes on, and then fades off again and then > nothing. I'm using a fresh install of gentoo linux, ix36, with XFree86 4.2.1 > > Any ideas? You could try current CVS, though it's not a good sign if not even the BIOS manages to display something... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: VBlank interrupt?
On Mit, 2002-10-23 at 20:40, Matan Ziv-Av wrote: > Svgalib's kernel module has an ioctl that waits for retrace, using the > card's interrupt. This functionality of the module is independent of > svgalib, and can be used also in X11, text mode or fbdev. Similar for the DRM ioctl, but it requires a privileged client like the X server to enable the interrupt. How is that handled by the svgalib kernel module? Also, I suspect that the svgalib module relies on a BIOS whereas the DRM has no such dependencies. It might be a good idea to write a small library which uses any of these means if present, so apps can easily take advantage of them. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]cirrus on powerpc
On Mon, 2002-10-21 at 18:33, Marc Dietrich wrote: > > I have a cirrus gd5446 with 1 mb memory installed in a Motorola > Powerstack 4400 (PCI PPC) running linux (kernel 2.4.17pre1, suse 7.3). I > think the cirrus driver is not endian save, because it crashes my system > hard. I can't even get the framebuffer driver to work. What's the problem with the fbdev driver? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]VBlank interrupt?
On Die, 2002-10-22 at 23:12, Tony Wu wrote: > Does XFree86 video driver support VBlank(Vsync) interrupt? If it does, how to enable >it? > I know some librarys offer function calls to sync to Vsync (linke SDL_Flip), but >they use > polling instead Vsync interrupt. The performance suffers a lot. > > I did some experiment by probing the vidoe interrupt pin on the AGP VGA card. It's >active > under MS Windowns but not Linux. I just don't know why Linux doesn't support a basic >and vital > function like vsync interrupt? The DRM in DRI CVS has an ioctl for this. Only the radeon DRM implements it so far, but mga is in the works and it shouldn't be hard to add for the others. You may want to check the dri-devel archives and maybe ask there. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On Die, 2002-10-22 at 17:34, Marc Aurele La France wrote: > On 22 Oct 2002, Michel Dänzer wrote: > > > > As far as I'm concerned, this issue is closed until such a time when the > > > kernel folk again rename something they shouldn't. > > > Can't you see that the kernel folks can do whatever they want, so long > > as people use a sane setup where there are no kernel headers in > > /usr/include? > > glibc's /usr/include/linux/kd.h ultimately hails from the kernel's > include/linux/kd.h. The field name change was propagated through this > system's upgrade to a bleeding edge glibc. Less bleeding edge than the kernel it was built against, apparently, or I'd expect it to deal with the rename. > My argument stands. It always does, no need to spell it out... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On Die, 2002-10-22 at 16:55, Marc Aurele La France wrote: > On 22 Oct 2002, Michel Dänzer wrote: > > > > 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. > > > I'm sure you mean the sane technical solution explained in > > http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html ? > > I'd be able to tell you if that site currently accepted connections. Works here, but you can try http://marc.theaimsgroup.com/?l=linux-kernel&m=96468376406463&w=2 instead. > But, again, where /usr/include/linux/kd.h comes from is irrelevant to the > reported problem. Definitely not. > As far as I'm concerned, this issue is closed until such a time when the > kernel folk again rename something they shouldn't. Can't you see that the kernel folks can do whatever they want, so long as people use a sane setup where there are no kernel headers in /usr/include? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On Die, 2002-10-22 at 14:23, Dr Andrew C Aitchison wrote: > On 22 Oct 2002, Michel Dänzer wrote: > > > > 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. > > > > I'm sure you mean the sane technical solution explained in > > http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html ? > > I'm tempted to think that the whole problem comes about because > the phrase "kernel headers" is used to cover both kernel headers and > glibc headers, which ought to be two distinct interfaces. > > Whenever I read why the kernel headers should be updated with the kernel, > but should match the version of glibc I see examples of programs which > appear to be linked against glibc, not against the kernel. Yes, the point is that userspace apps normally only need and should only use the glibc headers. Only kernel modules normally need the actual kernel headers. If a userspace app really does need kernel headers but (understandably) doesn't want to deal with their volatile nature, it should have its own copy of what it needs, like we have programs/Xserver/hw/xfree86/fbdevhw/fbpriv.h . -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Another CVS problem
On Mon, 2002-10-21 at 16:44, Marc Aurele La France wrote:
> 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.
I'm sure you mean the sane technical solution explained in
http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html ?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Status of Radeon support under XFree86
On Die, 2002-10-22 at 08:15, Kacper Wysocki wrote: > > 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. Must be something else, there's no relation whatsoever between the two that I can think of. Note that the XFree86 glx module is called libglx.a and isn't equivalent to hardware acceleration. > > > 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. Weird, there have been problems with the daily snapshots, but I haven't gotten any such reports about my Debian packages before. Please provide logs, config files etc. > 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. What binaries exactly? > > > * 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. There have been several reports of crashes when running with dualhead by Mandrake users; one prominent feature of Mandrake is that they merge GATOS code into their XFree86 packages, but maybe they just do it badly. > > 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? It will probably only work if you re-flash it with an OF ROM. I think people have done this. > What about a GeForce 3 Ti? (I've looked into the > matter and it seems the mac firmware does not exist) You'd be lucky to get decent 2D acceleration going for that, no 3D. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] r200 and libxaa
On Mon, 2002-10-21 at 02:05, Jens Owen wrote: > José Fonseca wrote: > > On Wed, Oct 16, 2002 at 04:52:59PM +1000, Simon Bland wrote: > > > >> I've seen ppl mention the libxaa.a from Fonseca seems to fix the problem > >> with the screen blanking. Thing is I can't seem to find this libxaa.. > >> Can anyone point me in the right direction for this? And can anyone > >> confirm that this does seem to fix the screen blanking problem with the > >> Radeon 8500. > >> > > > > Initially I hosted on my website because there was no certain that it > > would help. But now that I know it does I've moved it to > > http://dri.sf.net/snapshots/extras/libxaa.a.bz2 and wrote a README.Sig11 > > on http://dri.sf.net/snapshots/ . > > Can anyone on Xpert comment on XAA binary incompatability? Does this > just affect Forward compatability, i.e. older X environments with newer > binary drivers? The problem appeared when I merged radeon driver fixes by Kevin E. Martin from XFree86 CVS to DRI CVS. They involved adding new fields to the XaaInfoRec struct; the fact that they were added in the middle of that struct caused the DRI binary snapshots, which were built against the new version of that struct but ran with an XAA module built against the old version, to crash and burn. I moved the new fields to the end of the struct, bumped the minor XAA version and added code to the radeon driver to only access the new fields if it's dealing with the new XAA. That worked as expected when I tested it here by copying libxaa.a from my Debian 4.2 installation into my DRI tree, which makes me suspect that the remaining problem with the snapshots is due to toolchain incompatibilities or something along those lines. Hope this clarifies. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VTswitch
On Sam, 2002-10-19 at 14:12, David Dawes wrote: > On Sat, Oct 19, 2002 at 12:04:43PM +0200, Charl P. Botha wrote: > > >PS As things have been explained in this thread, it seems that X should not > >make any assumptions about hardware state when returning from VT. Would > >this mean that all Radeon (e.g.) hardware setup will have to be re-performed > >(e.g. re-installing the GPU microcode, performing all register outputs for > >setting up AGP, etc) after switching back from VT? If this is the case, > > Yes. Suppose something else that ran in the meantime installed different > microcode, or made other changes to the HW state? Right, nice argument for my DRI reinit patch and/or Charl's resume patch. :) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VTswitch
On Sam, 2002-10-19 at 14:16, David Dawes wrote: > On Fri, Oct 18, 2002 at 07:37:03PM -0400, Mike A. Harris wrote: > > >If the CVS code does lockup however, then I think it makes sense > >to put Charl's patch back in. > > It doesn't, and continuing speculation to the contrary isn't helpful. Neither is your ignoring Tom's report? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SIGFPE in Radeon 7500 DRI support
On Don, 2002-10-17 at 20:20, David Hampton wrote: > On Thu, 2002-10-17 at 05:06, Michel Dänzer wrote: > > > Program received signal SIGFPE, Arithmetic exception. > > > 0x40771fbb in gl_test_os_katmai_exception_support () > > >from /usr/X11R6/lib/modules/dri/radeon_dri.so > > > (gdb) bt > > > #0 0x40771fbb in gl_test_os_katmai_exception_support () > > ^^^ > > This is such a wonderfully expressive function name, why doesn't anybody > > read it? :/ > > Yes, it is a nice expressive name, but my expertise is in network > protocols not in video drivers. I don't know what Katmai is, why I need > it, why its not in my Red Hat kernel, where to find it, or why the lack > of it is crashing every OpenGL application on my computer. If this > function is expected to create a SIGFPE, why isn't it trapped and > handled? It is, that's the point. gdb stops on it nevertheless. You can avoid that with handle SIGFPE nostop, but then you'll miss unexpected SIGFPEs... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]gdb on ia64
On Don, 2002-10-17 at 17:26, Johannes Rath wrote: > I have installed gdb with support for xfree modules (5.1.1-2.0xfree) on ia64 > machine, but I am still not able to see the symbols of my module inside gdb. Did you call module /path/to/modules before the backtrace? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]SIGFPE in Radeon 7500 DRI support
On Mon, 2002-10-14 at 04:48, David Hampton wrote: > I looked through the last three months of the archives for this mailing > list and didn't see anything that quite matched my problem. I get a > crash in the DRI code any time I try to run a GL application, while > everything else seems to run fine. My hardware is a Radeon 7500 QW > board in a DELL Dimension 8100. I'm running RedHat 8.0 with XFree > 4.2.0 (redhat packages), although I also saw this problem with RedHat > 7.3. I've attached a stack trace and my XF86config-4 file. If anyone > can give me any pointers I'd appreciate it. Thanks. [...] > Program received signal SIGFPE, Arithmetic exception. > 0x40771fbb in gl_test_os_katmai_exception_support () >from /usr/X11R6/lib/modules/dri/radeon_dri.so > (gdb) bt > #0 0x40771fbb in gl_test_os_katmai_exception_support () ^^^ This is such a wonderfully expressive function name, why doesn't anybody read it? :/ It's the normal procedure to test for Katmai support, just continue. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI IGP Intergrated U1 Graphics
On Mit, 2002-10-16 at 09:34, Russell Jackson wrote: > I recently purchased a Compaq Presario 900Z which has the new ATI IGP > chipset containing a Radeon 7000 (7500?) graphics accelerator. > > Currently, the ati driver does not detect this graphics adapter. Since > this adapter is supposed to be a Radeon 7000/7500, I would assume it would > take little work to get it supported. You can verify your assumption by overriding the ChipId. > Are there any plans to support this chipset in the near future? Maybe > a better question would be if anyone has ever even heard of this > chipset before. ATI usually submits patches to add support for new chips pretty quickly. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VTswitch
On Don, 2002-10-17 at 04:50, David Dawes wrote: > On Tue, Oct 15, 2002 at 12:28:27AM +0200, Charl P. Botha wrote: > >On Mon, Oct 14, 2002 at 04:14:22PM -0600, Marc Aurele La France wrote: > >> On Tue, 15 Oct 2002, Charl P. Botha wrote: > >> > This would mean that the bug is back and people will again have the stupid > >> > >> No, it doesn't. > >> > >> > VT switch lockup. What would be the New and Improved Way(tm) way of > >> > explicitly re-enabling bus-mastering at RADEONEnterVT() time since > >> > xf86EnablePciBusMaster() has been deprecated? > >> > >> Just like the change notice says: When a PCI device is enabled, it's bus > >> mastering is also enabled. This occurs before any driver code is > >> executed. > > > >I'm running the DRI tree, so I can't test. However, we still don't know why > >these cards disabled bus mastering at VT switches (when it was very clearly > >enabled before the switch), so what guarantees that they won't still do > >this? Mike (Harris), do you have one of the affected cards running XFree86 > >HEAD? > > No, the X server restores changes is makes to the PCI state when it > gives up control of the console, so if bus mastering wasn't enabled > *before* the X server started, it won't be after VT switching away. > Several drivers had bugs where they didn't re-enable it when switching > back. Drivers shouldn't assume anything more about the HW state after > returning from a VT switch than they would at startup, but unfortunately > some still do... > > Marc's change means that drivers don't need to care about bus mastering > being enabled because it will now be enabled automatically for PCI cards > that are being used by the X server. Sounds good, unfortunately it doesn't seem to work for the original poster - any idea why? -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VTswitch
On Die, 2002-10-15 at 15:12, Charl P. Botha wrote: > On Tue, Oct 15, 2002 at 03:01:35PM +, Tom wrote: > > Why does ur driver is not included in cvs? > > :o/ > > it should resolve a lot of problem !! ;o) No, the problem is only with the binary snapshots, if you build yourself from CVS it should work fine. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VTswitch
On Die, 2002-10-15 at 14:17, Charl P. Botha wrote: > On Tue, Oct 15, 2002 at 02:05:53PM +, Tom wrote: > > > I tried the dri.sourceforge.net drivers, but i have a blank screen.. > > We could try to diagnose this if you want to. This has been hashed to death on dri-devel. It's a binary incompatibility that can be worked around by using libxaa from DRI CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XF86 4.2.0 + Radeon == No valid mode found for thisDFP/LCD
On Sam, 2002-10-12 at 13:42, martin f krafft wrote: > I've been experiencing major problems with X ever since the 4.2.0 > upgrade. This particular problem is on a laptop with a Radeon Mobility > M6 LY Video card running a custom 2.4.19+grsecurity kernel with the > 'radeon' kernel module loaded. 'agpgart' is compiled into the kernel. > > I am almost sure this has been discussed in the past, but I could not > find it in the archives. Thus I appreciate if you point me to a link > to prevent duplicate discussion. > > The problem is here in the logs: > > (WW) RADEON(0): Mode 1280x1024 is out of range. > Valid mode should be between 640x480-640x480 > (EE) RADEON(0): No valid mode found for this DFP/LCD > > X doesn't start until I enable the 640x480 mode (which is usually not > even included in XF86Config-4 -- no way I could work that way. > The configuration was not changed since X 4.1.0, where everything > worked. > > The result is that I can start X at 640x480 (WOW, BIG LETTERS) but at > no other resolution, not even 800x600. > > I can start into 1280x1024 when I use the "vesa" driver instead of the > native "radeon" driver, but then I loose a lot of performance, which > I don't want. > > You can download my XF86Config-4 file here > http://diamond.madduck.net/XF86Config-4.gz > > and the corresponding XFree86.0.log file here > http://diamond.madduck.net/XFree86.0.log.gz > > Do you have any idea on how this can be repaired? The driver doesn't detect your panel correctly. Maybe Option "PanelSize" "1400x1050" helps. Current CVS (not 4.2.1) should work better. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
On Fre, 2002-10-11 at 04:31, Geoffrey wrote: > Michel Dänzer wrote: > > On Don, 2002-10-10 at 03:58, Geoffrey wrote: > > > >>I've been trying to get my dual head radeon ve working, gave up and > >>stuck another card in this box, rage pro (16mb). It appears from the > >>log that both are recognized, but then I get: > >> > >>Symbol fbdevHWGetLineLength from module > >>/usr/X11R6/lib/modules/drivers/r128_drv.o is unresolved! > > > > > > That's hardly the actual problem, we need more info from your log. > > I've attached it as well as the config file. I appreciate any further > insites. [...] > (--) PCI: (0:11:0) ATI Mach64 GP rev 92, Mem @ 0xd500/24, 0xd300/12, I/O @ >0xa800/8, BIOS @ 0xd4fe/17 ^^ > (--) PCI:*(1:0:0) ATI Radeon VE QY rev 0, Mem @ 0xd800/27, 0xd400/16, I/O @ >0xd800/8, BIOS @ 0xd7fe/17 It's a Mach64... > Section "Device" > Identifier "device2" > VendorName "ATI" > BoardName "ATI Rage Pro" > Driver "r128" ...not a Rage128. Try using "ati" here (in fact, that should work with any supported ATI chip). > Option "DPMS" > BusID "PCI:0:11:0" > EndSection > > Section "Device" > Identifier "device1" > VendorName "ATI" > BoardName "ATI Radeon" > Driver "radeon" > Option "DPMS" > Option "AGPMode" "2" > BusID "AGP:1:0:0" ^ Not sure this works either, but it probably doesn't matter as this is the primary device. > EndSection -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Status of ATI Radeon support under XFree86
On Fre, 2002-10-11 at 11:00, Kacper Wysocki wrote: > after following this list for a couple of weeks I have gotten nowhere > trying to acheive decent acceleration for my ATI Radeon QL (8500 > 128mb), and it doesn't seem many others have, either. > This is Status Quo: > > * The resident XF86 'ati' driver works, gives a display etc (I have a > perfectly working dual-head setup, if anyone is interested: a note > about this in the postscript), but I have yet to acheive anything but > software 3d and choppy window movement. Even xscreensaver runs > 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. > 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. > * Video/dvd playback with mplayer and xine is good, but only with the > rootmode direct-to-card vidix extention. Xv modes load, but give > nothing, sometimes distorted greens, sometimes a blue band, sometimes a > very thin sliver of the playing video is visible in the window. This should be fixed in current XFree86 and DRI CVS. > * The GATOS project and their ati.2 driver: I have for some reason not > gotten anywhere with this driver. If I install it, X just plain refuses > to load. No log, no nothing except a 'signal 11', and an occational > curruption of my XF86Config-4, if I'm running as root. I recently > posted to the gatos-devel forum, and it's too early to expect a reply. That seems to be normal when trying to run dualhead with GATOS drivers. > * Hard resets: Over the past weeks I've installed the XF86 4.2.0 > binaries, updated to 4.2.1, used woody deb packages (4.1.x), installed > gatos drivers etc etc and I am no longer sure what cominations of which > results in the computer _hard resetting_ when I start x |not in root|. > This has usually happened after either updating to 4.2.1 or using gatos > ati.2. I will try to experiment further, although I don't like it at > all- my harddrive filesystems don't like it at all. Debian sid just > updated their packages to 4.2.1-1 and things seem to be working. The DRM from GATOS is incompatible to the DRM from XFree86 or DRI; after you've used the first, you can't use the others until a reboot. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xv with G200: Size limits after upgrade to 4.2
On Don, 2002-10-10 at 22:56, Andreas Trottmann wrote: > > Michael Dänzer wrote: > > > If you do so, please consider working on DRI CVS and making the > > mga driver allocate offscreen memory for 3D more dynamically, like > > I've done for the radeon driver. > > I'll try... I think I know how to program, but I've never hacked > on such a big project before. > > Just to be sure that I start at the right end: Is the DRI CVS > you're talking about the one at > pserver:[EMAIL PROTECTED]:/cvsroot/dri as > described on http://www.xfree86.org/4.2.1/DRIcomp6.html ? Yes. > And do you happen to remember at which revision you changed the > radeon driver, so I could have something as a "template" so I can > see what I have to change? Not off the top of my head; I could look it up, but it might be enough for you to know that the relevant code is in the RADEONDRITransitionTo3d() function in programs/Xserver/hw/xfree86/drivers/ati/radeon_dri.c . -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
On Don, 2002-10-10 at 03:58, Geoffrey wrote: > I've been trying to get my dual head radeon ve working, gave up and > stuck another card in this box, rage pro (16mb). It appears from the > log that both are recognized, but then I get: > > Symbol fbdevHWGetLineLength from module > /usr/X11R6/lib/modules/drivers/r128_drv.o is unresolved! That's hardly the actual problem, we need more info from your log. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert](EE) RADEON(0): [drm] failed to remove DRM...
On Fre, 2002-10-04 at 20:45, Sean McGuire wrote: > > I have looked everywhere to try and get this error fixed. > > > (EE) RADEON(0): [agp] AGP not available Make sure the agpgart module is loaded before the radeon kernel module to fix this. > (EE) RADEON(0): [drm] failed to remove DRM signal handler > > I have a Radeon VE AGP, 2.4.19, pre-built XFree86 4.2.0 from Slackware > 8.1. The agpgart module is loaded ive also tried it with out being > loaded. My dmesg gives me the error > > [drm] Initialized radeon 1.6.0 20020828 on minor 0 You seem to be running from DRI CVS, probably a binary snapshot? Anyway, problems with DRI CVS should be discussed on the dri-devel list. > [drm:radeon_unlock] *ERROR* Process XXX using kernel context 0 Not sure if this is really a problem or harmless. > (==) RADEON(0): Silken mouse enabled > > The screen goes black for a moment then Signal 11. This problem has been reported many times to dri-devel already. It seems to be some kind of binary incompatibility in the binary snapshots. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xv with G200: Size limits after upgrade to 4.2
On Don, 2002-10-10 at 15:46, Dr Andrew C Aitchison wrote: > On Thu, 10 Oct 2002, Andreas Trottmann wrote: > > > I got a Matrox Millennium G200 AGP (rev. 1), with 8 MB RAM. I use > > a resolution of 1024x768 in 16bpp. > > > > Since I upgraded to XFree86 4.2.1 from 4.1.0 (which happened > > recently in Debian sid), I cannot use Xv anymore for big sources. > > > This applies to a "normal" run of X, including the "dri" modules. > > When starting X without "dri", either by starting two X servers > > at once (so the second one can't do dri), or by commenting out > > the 'Load "dri"' statement in XF86Config-4, then I can use Xv for > > all sizes (at least until 1024x768). > > > Now, the whole problem looks like a shortage of memory to me. > > But, in my limited knowledge, I think that 8 MB should be enogh > > to do both DRI and Xv up to 1024x768 in 16bpp. So, I'm now asking > > the list: > > /xc/programs/Xserver/hw/xfree86/drivers/mga/mga_storm32.c > has the comment: >/* If that gives us less than half the available memory, let's > * be greedy and grab some more. Sorry, I care more about 3D > * performance than playing nicely, and you'll get around a full > * framebuffer's worth of pixmap cache anyway. > */ > Somebody has decided that 3D is more important than Xv, and not provided > an option to disagree. > > You could use the Option "TexturedVideo", described in > xc/programs/Xserver/hw/xfree86/Options as: > This has XvImage support use the texture engine rather than the video > overlay. This option is only supported by the G200 and G400, and only in > 16 and 32 bits per pixel. Default: off. > > IIRC using the texture engine is slower than the video overlay, but > it would use 3D memory, so might help in your particular case. > > Other than that you will have to modify the source of mga_storm32.c > and compile the driver yourself. If you do so, please consider working on DRI CVS and making the mga driver allocate offscreen memory for 3D more dynamically, like I've done for the radeon driver. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xserver configuration HOWTO?
On Mon, 2002-10-07 at 23:45, Frank Wang wrote: > > I have developed a RAM based frame buffer device for a spcial hardware > environment we have. It is very similar to the "virtual frame buffer" > device that comes with the RedHat 7.3. The output display is a TV monitor > which has a resolution of 720x480. At individual pixel level, I can see the > /dev/fb# works fine. But, when I run the X (version 4.2.0) on it, I am > getting a message saying, > > FBDEV(0): mode "720x480" test failed. > > I have traced the fb_set_var() and etc. on my frame buffer driver. They all > seems to returning the right value. Does your framebuffer device support FB_ACTIVATE_TEST? > Since this is a strictly RAM based frame buffer driver, the timing > calculation is pretty loose. When the mode pool is empty, the fbdev driver attempts to use the current mode from console: (**) FBDEV(0): Built-in mode "current": 28000.0 MHz, 3.9 kHz, 81018.5 Hz (II) FBDEV(0): Modeline "current" 28000.00 720 720 720 720 480 480 480 480 -hsync -vsync -csync This looks pretty bogus to me. The idea is that setting that mode should lead to the same video settings as were in use in console when starting the server. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]x 4.2.1 and radeon mobility
On Mon, 2002-09-09 at 14:35, Hanno Böck wrote: > i have a radeon mobility m6 ly. > as you know, this card had big problems with 4.2.0 because the system > hang every time i switched to console and back. > > now, this hang is fixed in 4.2.1, but dri doesn't work at all. if i > start glxinfo, it says that direct rendering is enabled, but if i run > opengl-programs (e.g. glxgears), i don't get anything, just a black > window/screen. The output of LIBGL_DEBUG=verbose glxinfo would be interesting. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]problem with LCD display flickering
On Mit, 2002-10-09 at 14:19, Alexander Stohr wrote: > > LCDs might be seinsitive to precise signal timings. > You might to try tuning them a bit up or downwards. > > > every once in a while (30 sec - 60 sec), the LCD screen would > > flickers. > > > > Driver is ati on Dell server. If it's a Mach64 card, Option "CompositeSync" "off" might help. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Problem with Radeon 7500 Config
On Mon, 2002-09-30 at 18:16, Kraft Nicholas A wrote: > I am trying to run two ViewSonic EA771 monitors off of my radeon 7500 > (retail box). I would like to use Xinerama. I get a server crash using > this file which I have pieced together from past posts. [...] > Build Operating System: Linux 2.4.18-23mdkenterprise i686 [ELF] Known problem with Mandrake. Stock XFree86 has been reported to work. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Resolution change in ATI Rage Mobility M3 problem
On Mit, 2002-09-25 at 14:56, [EMAIL PROTECTED] wrote: > *** Resolution change in ATI Rage Mobility M3 problem od Dell C600 > Latitude laptop. Ask for help *** > > On my Dell C600 laptop works X well in 1024x786 reaolution, there > is no problem, but I would like to get LOWER resolution 640x480 in > some occasions. > (I would like to play TuxRacer fullscreen ;-)) > > Whatever I set in XF86Config-4, setting "Display" subsection as > suggested in forums, setting modelines directly, restricting Modes > in display subsection to only 640x480 resolution; X starts still > only in 1024x786! > > And worse yet, CTRL ALT +/- DOESN'T WORK! After pressing, nothing > happens. It looks like, X select "smartly" only the best > resolutin, whatever I write to config file. > (In another words, it's ignoring me :-)) [...] > Section "Monitor" >Identifier "Generic LCD Panel 1024x768" >VendorName "Unknown" >ModelName "Unknown" >HorizSync 31.5-48.5 >VertRefresh 40-70 [...] > (II) R128(0): Generic LCD Panel 1024x768: Using hsync range of > 31.50-48.50 kHz > (II) R128(0): Generic LCD Panel 1024x768: Using vrefresh range of > 40.00-70.00 Hz > (II) R128(0): Clock range: 12.50 to 250.00 MHz > (II) R128(0): Not using mode "640x480" (hsync out of range) > (II) R128(0): Not using mode "640x480" (hsync out of range) No, it's not ignoring the sync ranges you provide. ;) -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Time-machine messages
On Mit, 2002-10-09 at 07:51, Kacper Wysocki wrote: > Does anyone have a reasonable explenation for why I just received a > huge amount of Xpert digests, all with correct sequential no's, that > are full of messages dated August?! Is the listserver date/time screwed > up or something? I'm talking Vol 1, #2268 up to #2277, but I seem to be > missing #2266-7, #2270-1, #2274 and possibly more to come. And an > amazing amount of postings for one day, if I might add. True. It's probably someone clearing up the administrative backlog of the list. I question the value of months old posts though, most of those issues will have been resolved by now. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PowerBook III locks up using the HEAD ati driver(previous HEAD builds were okay)
On Fre, 2002-10-04 at 06:41, Miles Lane wrote: > > I am running XFree86 HEAD on a Titanium PowerBook III/800 > with a 2.4.20-pre7-ben0 kernel built from Benjamin Herrenschmidt's > rsync tree. For the last couple of days, when I build from cvs HEAD, > starting X has locked up my display (I cannot switch away from > the locked tty7). My kernel is still running, because the CAPSLOCK > light still toggles. So it did when my machine didn't power on and I had to send it in for repair... I usually try to ping it to determine if the kernel is up. > Anyhow, I have had only minor problems with the ati driver for the > last couple of months. I am running radeonfb in the kernel and > have the following settings in XF86Config: > > Section "Module" > Load"GLcore" > Load"bitmap" > Load"dbe" > Load"ddc" > # Load"dri" > Load"extmod" > Load"freetype" > Load"glx" > Load"int10" > Load"pex5" > Load"record" > Load"speedo" > Load"type1" > Load"vbe" > Load"xie" > EndSection That's a bit excessive, have you tried removing at least int10 and vbe? > The problem I have had with the ati driver prior to hitting this > display lockup problem was that sometimes when I would switch > between a VT window and the X display (or vice versa), the display > would show a sequence of three scanlines all starting at > different points. So, line 1, 4, 7, 10, ... would start at the > right edge of the screen, lines 2, 5, 8, 11, ... would be indented > about 1/8 of the screen and lines 3, 6, 12, 13, ... would be > indented 1/4 of the screen. Switching back and forth between a VT > and the X display would usually clean up the problem. > Very occaisionally the machine would lock up and need a cold boot. > There was also a scrolling effect, where unsynced lines would seem > to be scrolliny up slowly up. [...] > It is worth noting that the fbdev driver is working pretty well, > though it exhibits the same problem that the ati driver used to > have. That is, sometimes when switching between a VT and the > X display (or vice versa), the display is munged with unsynced > scanlines. That's a radeonfb glitch. The one to find and fix it gets the prize. :) > (EE) FBDEV(0): FBIOPAN_DISPLAY: Invalid argument That's also a radeonfb bug, I sent a fix to Ben and Ani and Ben is merging it into his tree right now. The second log you posted was still from the fbdev driver BTW. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 7500 Problem
On Die, 2002-10-01 at 20:42, Nick Kraft wrote: > Thanks for responding. I think I did what you suggested. I commented > out the line in my config file: Load "vl4" in the Modules section. I > also switched the driver from "radeon" to "ati" in the two device > sections. Still no luck. Of course, I'm not really sure if that is > considered using the stock XFree86 driver. It's not, it's still the same patched driver from Mandrake. The stock driver would be either from an XFree86 binary tarball or built yourself from source. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xv and OpenGL -- new module idea
On Mon, 2002-09-30 at 22:14, Alex Deucher wrote: > I'm pretty unfamiliar with OpenGL programming. I have an idea for an > xfree module that I suspect would not be too hard to implement, but I > wanted to get some other opinions on it. What I'd like to do is create > a module called perhaps ogl-xv or glx-xv that would provide a generic > Xv adapter on the front end and on the back end would implement it > using openGL calls to basically create an RGB or YUV texture to render > the video to. One problem I see is that the X server currently can't use 3D acceleration with the DRI; that would also be a way to achieve accelerated indirect rendering, so it would definitely be a worthwhile project though. > this would have the advantage of acceleration on cards with accelerated > 3D, and would provide generic Xv support to cards lacking an overlay > engine by using SW mesa, But that might be slower than not using Xv at all. > and it could provide for more than one Xv adapter, so you could > theoretically have more than one Xv at a time. That would certainly be nice, although one adapter seems to be enough usually. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon 7500 Problem
On Mon, 2002-09-30 at 22:50, Nick Kraft wrote: > Hi, I am having a problem setting up two monitors on my radeon 7500. I > have written a config file based on past posts, but I get a server crash > when using it. As it is I have identical pictures on both screens. My > log follows. I have disabling a few things such as DPMS and DRI; nothing > seems to help. [...] > (II) RADEON(0): Starting up Xvideo subsystems [...] > (**) RADEON(0): DPMS enabled > > Fatal server error: > Caught signal 11. Server aborting This seems to be a problem with Mandrake merging GATOS code into their drivers. Please ask either of them for support or come back here if it happens with stock XFree86 as well. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
