Re: [Dri-devel] Re: CVS Update: xc (branch: trunk)
Eric Anholt wrote: On Tue, 2003-10-07 at 10:42, Alex Deucher wrote: I have a question about the license at the top of these new files. what should I put for the copyright? Some of the the code was written by me, but much of it was taken from the sis and mga drivers. Also, what to I put for the top line? the one that looks like this: /* $XFree86: xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_cursor.c,v 1.25 2003/08/29 21:07:57 tsi Exp $ */ thanks, Alex Accepted practice, as far as I can tell, is that when you take code from one driver and adapt it into new files in another driver, you get to put your copyright on it. I've done this in the sis code, and VIA/S3 did it in the Savage code which still has a lot of Matrox code #ifdeffed out (or not, and just unused) in it. Yep, this is fine. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-cvs & miniglx merge
Otto Solares wrote: Hi! I am trying to merge the r200 driver from dri-cvs to mesa-miniglx, finally i had most files merged but i am finding heavy X dependencies in header files in dri-cvs (eg radeon.h), it was not supposed dri drivers should be backend agnostic? Is somebody working on resolving this situation? i think unified dri drivers should be a common goal. A number of people, including myself, are interested in seeing this happen. Unfortunately, there's also a heap of other things taking up our time. My current project is a tnl rewrite that actually predates this work on moving the DRI drivers over to mesa. I really want to get that sorted out first. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Another cvs policy question
Hi, I have a working copy of the config-0-0-1-branch with the trunk merged in now. According to the CVS policy I would have to commit this to the branch. However, this would be a huge commit due to the intermediate merge from XFree86. cvs diff -uN outputs a 323074-lines patch (11 MB). I believe it would unnecessarily blow up the repository. It should be sufficient to merge the config branch to a trunk working-copy and commit the result to the trunk. That would be a much smaller commmit. I don't intend to change the CVS policy in this respect, just asking if it would be ok to make an exception in this case. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another cvs policy question
Felix Kühling wrote: Hi, I have a working copy of the config-0-0-1-branch with the trunk merged in now. According to the CVS policy I would have to commit this to the branch. However, this would be a huge commit due to the intermediate merge from XFree86. cvs diff -uN outputs a 323074-lines patch (11 MB). I believe it would unnecessarily blow up the repository. It should be sufficient to merge the config branch to a trunk working-copy and commit the result to the trunk. That would be a much smaller commmit. What size is that patch? I don't intend to change the CVS policy in this respect, just asking if it would be ok to make an exception in this case. There's nothing that says you have to merge a branch to the trunk. If you've got a changeset that you want to apply to the trunk (ie a patch that applies cleanly against the trunk), we can consider that in isolation, regardless of whether it once related to a branch. I'd be interested to see the actual patch, in fact. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-cvs & miniglx merge
On Wed, Oct 08, 2003 at 12:53:29AM -0600, Otto Solares wrote: > Hi! > > I am trying to merge the r200 driver from dri-cvs to mesa-miniglx, > finally i had most files merged but i am finding heavy X dependencies > in header files in dri-cvs (eg radeon.h), it was not supposed dri > drivers should be backend agnostic? > > Is somebody working on resolving this situation? i think unified > dri drivers should be a common goal. > > And yes!, dri drivers should live in mesa tree instead of Xfree IMHO. Indeed. I'm working on this at the moment. But being able to do this with a degree of cross code sharing is tricky. MiniGLX uses a subset of the current DDX driver mechanism's to initialize the DRI. It would be nice if that code can be shared. Before that can happen though, is that we need dynamic back/depth buffer creation - which is what I'm currently working on. In fact, I'll probably be creating a branch in the DRI CVS pretty soon. I've used the r200 driver as a basis for this work. Alan. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another cvs policy question
On Wed, 08 Oct 2003 10:38:04 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: > Felix Kühling wrote: > > Hi, > > > > I have a working copy of the config-0-0-1-branch with the trunk merged > > in now. According to the CVS policy I would have to commit this to the > > branch. However, this would be a huge commit due to the intermediate > > merge from XFree86. cvs diff -uN outputs a 323074-lines patch (11 MB). I > > believe it would unnecessarily blow up the repository. It should be > > sufficient to merge the config branch to a trunk working-copy and commit > > the result to the trunk. That would be a much smaller commmit. > > What size is that patch? 2776 lines (93 KB) > > > I don't intend to change the CVS policy in this respect, just asking if > > it would be ok to make an exception in this case. > > There's nothing that says you have to merge a branch to the trunk. If you've > got a changeset that you want to apply to the trunk (ie a patch that applies > cleanly against the trunk), we can consider that in isolation, regardless of > whether it once related to a branch. > > I'd be interested to see the actual patch, in fact. It's attached. I made it on my notebook just now so I couldn't test it yet, but after my experience with merging the other way round I'm pretty confident that it works. > > Keith Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. config2trunk.diff.gz Description: Binary data
Re: [Dri-devel] Another cvs policy question
Felix Kühling wrote: On Wed, 08 Oct 2003 10:38:04 +0100 Keith Whitwell <[EMAIL PROTECTED]> wrote: Felix Kühling wrote: Hi, I have a working copy of the config-0-0-1-branch with the trunk merged in now. According to the CVS policy I would have to commit this to the branch. However, this would be a huge commit due to the intermediate merge from XFree86. cvs diff -uN outputs a 323074-lines patch (11 MB). I believe it would unnecessarily blow up the repository. It should be sufficient to merge the config branch to a trunk working-copy and commit the result to the trunk. That would be a much smaller commmit. What size is that patch? 2776 lines (93 KB) I don't intend to change the CVS policy in this respect, just asking if it would be ok to make an exception in this case. There's nothing that says you have to merge a branch to the trunk. If you've got a changeset that you want to apply to the trunk (ie a patch that applies cleanly against the trunk), we can consider that in isolation, regardless of whether it once related to a branch. I'd be interested to see the actual patch, in fact. It's attached. I made it on my notebook just now so I couldn't test it yet, but after my experience with merging the other way round I'm pretty confident that it works. Looks good. For my money it's fine to just get this patch working on the trunk and commit it there. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
Michel Dänzer wrote: On Mon, 2003-10-06 at 14:06, Helge Hafting wrote: Unfortunately, xserver-xfree86-dri-trunk from http://people.debian.org/~daenzer/dri-trunk-sid/ hangs my machine rather quickly. X comes up, and can be used in any way for a few seconds. (Rarely enough to log in via xdm) Then it just hangs - wether I actually do anything or merely watch it "time out fast and die". The hang is a bad one, not even the sysrq key can be used to force a reboot. Other experimental debian packages with X 4.3.0 has the same problem, so I guess it is a radeon driver issue and not something dri specific. Please provide the X server log and config files as well as any relevant output from 3D clients which cause problems (running the old X server) and the kernel. Attached: XFree86.0.log - logfile for the old X 4.2.1 that comes with debian testing XF86Config-4 - the config file currently in use. This X server works fine except if I try running 3D stuff. I can run glxinfo and get the output you saw, any attempt to use 3D just hangs without output. I can try stracing glxgears if that may help. Previous attempts to use X4.3 crashed leaving no logfile, I can try mounting the filesystems synchronously to capture that. I use kernel 2.6.0-test6 which is supposed to have new DRI stuff, at least Linus claimed to do a DRI merge a few weeks ago. Helge Hafting 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.1.1 (Debian 4.2.1-11 20030829103906 [EMAIL PROTECTED]) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 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.21-rc1-ac1-cryptoloop i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Oct 6 13:46:59 2003 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "BenqFP767" (**) | |-->Device "ATI Radeon" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "no" (**) XKB: layout: "no" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Configured Mouse" (WW) The directory "/usr/lib/X11/fonts/CID" does not exist. Entry deleted from font path. (**) FontPath set to "unix/:7100,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.2.1.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.2.1.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8098, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1039,0646 card 1039,0646 rev 00 class 06,00,00 hdr 80 (II) PCI: 00:01:0: chip 1039,0001 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 1039,0008 card , rev 04 class 06,01,00 hdr 80 (II) PCI: 00:02:1: chip 1039,0016 card , rev 00 class 0c,05,00 hdr 00 (II) PCI: 00:02:5: chip 1039,5513 card a0a0,5513 rev 00 class 01,01,80 hdr 00 (II) PCI: 00:02:7: chip 1039,7012 card a0a0,01f0 rev a0 class 04,01,00 hdr 00 (II) PCI: 00:03:0: chip 1039,7001 card a0a0,7001 rev 0f class 0c,03,10 hdr 80 (II) PCI: 00:03:1: chip 1039,7001 card a0a0,7001 rev 0f class 0c,03,10 hdr 00 (II) PCI: 00:03:2: chip 1039,7001 card a0a0,7001 rev 0f class 0
Re: [Dri-devel] radeon & Transition functions
W liście z pon, 06-10-2003, godz. 15:28, Keith Whitwell pisze: > > I know that vertex are accumulated and then are sent to the hardware. > > Is it possible (hard?) to do something like this in order to render > > into more than buffer. > > > > radeonSetBuffer(GL_FRONT_LEFT) > > radeonSendDataToHardware(); > > radeonSetBuffer(GL_FRONT_RIGHT) > > radeonSendDataToHardware(); > > Yes, that sort of thing is possible. > > If you look at the older 3d drivers, eg. r128, you'll see that we had to use a > loop to dispatch regular vertices as we could only send a few cliprects to the > kernel at a time. You could do a similar loop over the two buffers. Do You think that it would be better to first try to understand r128 driver (which is probably simplier than radeon) or the two drivers differ too much. -- Jacek Rosik <[EMAIL PROTECTED]> --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon & Transition functions
Jacek Rosik wrote: W liście z pon, 06-10-2003, godz. 15:28, Keith Whitwell pisze: I know that vertex are accumulated and then are sent to the hardware. Is it possible (hard?) to do something like this in order to render into more than buffer. radeonSetBuffer(GL_FRONT_LEFT) radeonSendDataToHardware(); radeonSetBuffer(GL_FRONT_RIGHT) radeonSendDataToHardware(); Yes, that sort of thing is possible. If you look at the older 3d drivers, eg. r128, you'll see that we had to use a loop to dispatch regular vertices as we could only send a few cliprects to the kernel at a time. You could do a similar loop over the two buffers. Do You think that it would be better to first try to understand r128 driver (which is probably simplier than radeon) or the two drivers differ too much. I'm only talking about a single function in r128_ioctl.c -- r128FlushVerticesLocked() which has a loop to submit drawing commands multiple times to the kernel. Keith --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] drm 'lockup' with i845G onboard graphics....
When I switch from an X session to the (text mode) VGA console, the kernel logs these messages and X gets killed: [drm:i830_wait_ring] *ERROR* space: 131048 wanted 131064 [drm:i830_wait_ring] *ERROR* lockup The mode I'm running in is 1600 x 1200 x 16bpp, and the Intel 845G Extreme Graphics core is allocated 8MB of graphics memory. Please CC me for more information. OS is RedHat Linux 9 with XFree86-4.3.0-2. --- # lspci -vxxx (vga controller) 00:02.0 VGA compatible controller: Intel Corp. 82845G/GL [Brookdale-G] Chipset Integrated Graphics Device (rev 01) (prog-if 00 [VGA])Subsystem: Compaq Computer Corporation: Unknown device 00b8 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f000 (32-bit, prefetchable) [size=128M] Memory at fc40 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 1 00: 86 80 62 25 07 00 90 00 01 00 00 03 00 00 00 00 10: 08 00 00 f0 00 00 40 fc 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 11 0e b8 00 30: 00 00 00 00 d0 00 00 00 00 00 00 00 0a 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 01 00 21 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (memory controller) 00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host Bridge (rev 01) Flags: bus master, fast devsel, latency 0 Memory at f800 (32-bit, prefetchable) [size=64M] Capabilities: [e4] #09 [0105] 00: 86 80 60 25 06 01 90 20 01 00 00 06 00 00 00 00 10: 08 00 00 f8 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 e4 00 00 00 00 00 00 00 00 00 00 00 40: 3c 03 00 00 41 20 10 20 04 01 00 00 1b 08 10 00 50: 00 00 44 00 00 00 00 01 1a 16 12 00 35 2c 3f 30 60: 08 08 08 08 00 00 00 00 00 00 00 00 00 00 00 00 70: 02 00 00 00 00 00 00 00 05 84 41 2b 71 c1 00 20 80: 5d 00 af 00 ad 00 00 00 01 00 00 00 00 00 00 00 90: 10 11 11 11 11 33 33 00 45 04 00 00 00 0a b8 00 a0: 02 00 20 00 17 02 00 1f 00 00 00 00 00 00 00 00 b0: 00 00 00 00 30 00 00 00 00 00 00 00 20 10 00 00 c0: 44 40 30 11 00 00 0c 0a 00 00 00 00 00 00 00 00 d0: 02 28 04 0e 0b 0d 00 10 00 00 11 b3 00 00 01 00 e0: 00 00 00 00 09 00 05 01 00 00 00 00 00 00 00 00 f0: 38 0e 00 00 74 f8 00 00 40 0f 00 00 04 00 00 00 (snip) -- Daniel J Blueman NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse für Mail, Message, More! +++ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-cvs & miniglx merge
it's be nice if we could merge radeon and r200 into one driver when we did this as well. Alex --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > On Wed, Oct 08, 2003 at 12:53:29AM -0600, Otto Solares wrote: > > Hi! > > > > I am trying to merge the r200 driver from dri-cvs to mesa-miniglx, > > finally i had most files merged but i am finding heavy X > dependencies > > in header files in dri-cvs (eg radeon.h), it was not supposed dri > > drivers should be backend agnostic? > > > > Is somebody working on resolving this situation? i think unified > > dri drivers should be a common goal. > > > > And yes!, dri drivers should live in mesa tree instead of Xfree > IMHO. > > Indeed. I'm working on this at the moment. But being able to do this > with a degree of cross code sharing is tricky. MiniGLX uses a subset > of the current DDX driver mechanism's to initialize the DRI. It would > be nice if that code can be shared. Before that can happen though, is > that we need dynamic back/depth buffer creation - which is what I'm > currently working on. > > In fact, I'll probably be creating a branch in the DRI CVS pretty > soon. > I've used the r200 driver as a basis for this work. > > Alan. > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri-cvs & miniglx merge
On Wed, Oct 08, 2003 at 09:48:16AM +0100, Keith Whitwell wrote: > Otto Solares wrote: > >Hi! > > > >I am trying to merge the r200 driver from dri-cvs to mesa-miniglx, > >finally i had most files merged but i am finding heavy X dependencies > >in header files in dri-cvs (eg radeon.h), it was not supposed dri > >drivers should be backend agnostic? > > > >Is somebody working on resolving this situation? i think unified > >dri drivers should be a common goal. > > A number of people, including myself, are interested in seeing this happen. > Unfortunately, there's also a heap of other things taking up our time. My > current project is a tnl rewrite that actually predates this work on moving > the DRI drivers over to mesa. I really want to get that sorted out first. Good! if you need help because time contraints just say a word, even you could tell me what to do and verify if am doing right, i am very interested in this goal. -solca --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Broken Xv in current trunk?
Hello, if I try to use Xv (via mplayer, or with xawtv using the v4l-module) with current cvs (trunk) the X server crashes. I'm using a r200-based card (Radeon 8500). When I check out cvs from just before the mergedfb-merge (i tried 2003-10-07, 4:30:00), I get no problems, so the merge might have broken something. Can anybody reproduce this? regards, Stefan --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
Stefan Lange wrote: Hello, if I try to use Xv (via mplayer, or with xawtv using the v4l-module) with current cvs (trunk) the X server crashes. I'm using a r200-based card (Radeon 8500). When I check out cvs from just before the mergedfb-merge (i tried 2003-10-07, 4:30:00), I get no problems, so the merge might have broken something. Can anybody reproduce this? Yes, I can confirm that (in fact just wanted to report it and saw your mail). I didn't try with just-before-mergedfb-merge version though. xawtv without the v4l-module works fine as long as overlay is used. But selecting grabdisplay or starting mplayer instantly segfaults the X server. Roland btw sorry if this email appears way after the bug has been fixed - I often get 2-3 days delays lately sending to the list, something looks to be wrong with the list server. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri hangs the pc (radeon 7000/VE, SiS645DX AGP)
On Tue, 2003-10-07 at 11:44, Helge Hafting wrote: > > I did some more experiments with these packages: > xserver-xfree86-dri-trunk xlibmesa-gl1-dri-trunk BTW, there are new versions available, I suppose they don't make a difference? > xdm manages to start, but displays an ugly black & white window. > I have attached the Xfree86 logfile from this run. > > I can type in username & password, but the session fails to start > and xdm appear again. The log shows xdm authorization problems explained in /usr/share/doc/xserver-xfree86-dri-trunk/README.Debian . > I can usually fix that sort of thing but not with an unstable xserver. > Running "startx" as root gives me a black screen and dead pc. No sysrq, > I need the reset switch on the case. Weird that xdm and startx behave differently. > So I got rid of the bad xserver but kept xlibmesa-gl1-dri-trunk. > glxinfo now shows a lot more info and a newer version. > This is attached as the file "glxinfo2" > > Glxgears still hangs if I run it. The hang is not as > bad as the xserver hang, because I can use sysrq+S+U+B > to reboot without messing up filesystems. Can you also try logging in remotely and killing glxgears? > I have attached two strace files for glxgears. > gears.strace.gz is for the old mesa, > gears2.strace.gz is for the new dri-trunk stuff. Interestingly, they seem to be virtually identical. In particular, they both hang in a select() on the DRM device. Unfortunately, I don't know what that's about. > The kernel is still 2.6.0-test6 I wonder if that could matter. Can you try a 2.4 kernel? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
On Wed, 2003-10-08 at 22:30, Stefan Lange wrote: > Hello, > if I try to use Xv (via mplayer, or with xawtv using the v4l-module) > with current cvs (trunk) the X server crashes. I'm using a r200-based > card (Radeon 8500). > When I check out cvs from just before the mergedfb-merge (i tried > 2003-10-07, 4:30:00), I get no problems, so the merge might have broken > something. > > Can anybody reproduce this? I could, and I just fixed this in CVS. The cause was dereferencing a pointer which is uninitialized in non-MergedFB mode. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
that's my fault. there's a small bug that I missed that breaks Xv in non-mergedfb mode. I have the fix. it will be committed ASAP. Alex --- Stefan Lange <[EMAIL PROTECTED]> wrote: > Hello, > if I try to use Xv (via mplayer, or with xawtv using the v4l-module) > with current cvs (trunk) the X server crashes. I'm using a r200-based > > card (Radeon 8500). > When I check out cvs from just before the mergedfb-merge (i tried > 2003-10-07, 4:30:00), I get no problems, so the merge might have > broken > something. > > Can anybody reproduce this? > > regards, > Stefan > > > > --- > This SF.net email is sponsored by: SF.net Giveback Program. > SourceForge.net hosts over 70,000 Open Source Projects. > See the people who have HELPED US provide better services: > Click here: http://sourceforge.net/supporters.php > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
On Thu, 9 Oct 2003, Michel Dänzer wrote: > > I could, and I just fixed this in CVS. The cause was dereferencing a > pointer which is uninitialized in non-MergedFB mode. It's still broken on i845, though. No crashes, but Xv windows show up as all blue (I assume that's the overlay color), and the X server takes up 100% CPU time when trying to play anything. As a result, everything turns very jerky indeed, as other X clients end up getting delayed by the (broken) Xv support. It's been broken for at least a few weeks. I don't know what I can do to help debug it, but I'll happily test patches. Linus --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-08-10 21:40 --- I give some more informations : - My laptop is a Compaq Presario 2141ea (French model) [EMAIL PROTECTED]:~$ lspci 00:00.0 Host bridge: ATI Technologies Inc: Unknown device cab0 (rev 13) 00:01.0 PCI bridge: ATI Technologies Inc U1/A3 AGP Bridge [IGP 320M] (rev 01) 00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) 00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02) 00:07.0 ISA bridge: ALi Corporation M1533 PCI to ISA Bridge [Aladdin IV] 00:08.0 Modem: ALi Corporation Intel 537 [M5457 AC-Link Modem] 00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) 00:11.0 Bridge: ALi Corporation M7101 PMU 00:12.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility U1 [EMAIL PROTECTED]:~$ seems to be very close to Fujtisu Amilo. - My changes to linux 2.6.0-test6 was very small : s/dev_priv->agp/dev_priv->gart/g to the patch. I say that from memory, because when I've tryed that kernel, I didn't think it can work... I'm using this kernel now. I'm repeating, I've done the same tests with 2.6.0-test4, so my change is not the troubles, because it don't work with 2.6.0-test4 too... If I can (and have the motivation), I'll try to connect to my laptop with ssh to see what happen. If you want more informations, answer. Sorry to have posted 2 times my bug report. Thanks. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Broken Xv in current trunk?
A fix just went into xfree86 CVS earlier today that fixed several things related to Xv on i8xx hardware. that code hasn't been synced with DRI CVS yet. I don't have intel hardware so I can't test. The problem with Xv on radeon was a bug in my mergedfb code, but it's fixed now. Alex --- Linus Torvalds <[EMAIL PROTECTED]> wrote: > > On Thu, 9 Oct 2003, Michel Dänzer wrote: > > > > I could, and I just fixed this in CVS. The cause was dereferencing > a > > pointer which is uninitialized in non-MergedFB mode. > > It's still broken on i845, though. > > No crashes, but Xv windows show up as all blue (I assume that's the > overlay color), and the X server takes up 100% CPU time when trying > to > play anything. As a result, everything turns very jerky indeed, as > other X > clients end up getting delayed by the (broken) Xv support. > > It's been broken for at least a few weeks. I don't know what I can do > to > help debug it, but I'll happily test patches. > > Linus > __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
