[Dri-devel] Hi ! drgqibiuhjm la sa
Title: aires HI,Dri-announce BANNED CD! I have been receiving emails saying that I'm contributing to the moral decay of society by selling the Banned CD. That may be, but I feel Strongly that you have a right to benefit from this hard-to-find information. So I am giving you ONE LAST CHANCE to order the Banned CD! With this powerful CD, you will be able to investigate your friends, enemies and lovers in just minutes using the Internet. You can track down old flames from college, or you can dig up some dirt on your boss to make sure you get that next promotion! Or maybe you want a fake diploma to hang on your bedroom wall. You'll find addresses for companies that make these diplomas on the Banned CD. Need to disappear fast and never look back? No problem! Using the Banned CD, you will learn how to build a completely new identity. Obviously, the Powers That Be don't want you to have the Banned CD. They have threatened me with lawsuits, fines, and even imprisonment unless I stop selling it immediately. But I feel that YOU have a Constitutional right to access this type of information, and I can't be intimidated. Uncle Sam and your creditors are horrified that I am still selling this product! There must be a price on my head! Why are they so upset? Because this CD gives you freedom. And you can't buy freedom at your local Walmart. You will have the freedom to avoid creditors, judgments, lawsuits, IRS tax collectors, criminal indictments, your greedy ex-wife or ex-husband, and MUCH more! PLEASE CLICK! To Be Removed From Our List, CLICK HERE: Remove My Address d e eafabyb t uniaxialc ncofj
[Dri-devel] Re: our conversation yesterday
People That Want Sex Make your own sexual reality by meeting real women who want sex now and fuck them wherever you want! Join the best matchmaking site on the web now! --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] spam collection of the past few days
On Mon, Jun 16, 2003 at 02:52:45AM +0200, Alexander Stohr wrote: In response to the attached list of spam (18 spam e-mails to dri-devel in only 3 days!) i have to ask if the dri-devel mailing list can now be set to subscribers-only policy? Notice that removing html only mail as well as multi-part with only html part mail should catch most if not all of those spams. Friendly, Sven Luther --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Help..
21gw303e2gcvvnxas5g09prx10 Stop Mailings Here paskrr1heiqnowa98m4181e8
[Dri-devel] I dont even know
Get your medication prescribed online and shipped to your door overnight! Click Here to Enter! One of our US licensed physicians will write an FDA approved prescription for you and ship your order overnight via a US Licensed pharmacy direct to your doorstep, fast and secure! Our new super-reliable pharmacies get your order to your doorstep the next day as long as you order before 2pm. WEIGHT LOSS: Lose weight NOW! Why bother to diet when you can SHED THE POUNDS AWAY with prescription drugs like PHENTERMINE, ADIPEX, and DIDREX. MUSCLE RELAXERS: End muscle pain NOW! Forget the Doctor, GET IT TOMORROW! SOMA, CYCLOBENZAPRINE, FLEXERIL, and more PAIN RELIEF : End pain NOW! FIORICET, ULTRAM, and more. ANTI DEPRESSANTS: Too Depressed to go to the Doctor? Buy it ONLINE!!! PAXIL, PROZAC, ZOLOFT, WELLBUTRIN, and more! SLEEPING AIDS: Having trouble getting to sleep? AMBIEN and SONATA ONLINE! VIAGRA: Erectile Dysfunction is a common problem among men today. Avoid the embarrasment of going to the Doctor, buy it online now! Click Here to Enter! Stop Receiving the offers --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Best penis enlargement on the market uqwjxquniobrcmnlg x
Title: HUGE DICK OR YOUR MONEY BACK! GET A BIGGER PENIS OR YOUR MONEY BACK! Key Benefits FAST-DISCREET-SECURE PRIORITY SHIPPING! -Money back guarantee -Scientist approved -gain multiple inches -no pumps, no surgery, no exercises -increase penis width -produce stronger, harder errections -helps premature ejaculation Click here for details Guaranteed to add 3+ inches! Max Girth is the worlds quickest, easiest, and safest way to add 3-5 inches to your manhood. We are so confident it will make your penis bigger that we offer a 100% money back guarantee. No other formula compares to Max Girth, period. In a recent study, 67% of women admitted not being happy with their partners penis size. It's time to give your girl something to yell about! YOU HAVE NOTHING TO LOOSE AND EVERYTHING TO GAIN! CLICK HERE! You have received this e-mail because at one time or another you entered your email address into an adult oriented database. If you have received this e-mail in error, we apologize for the inconvenience. Please click here to get removed from our mailing list. We honor ALL remove requests. thkhactcttjlknventm yxfepqfj gceikeelcyxb aexuwv mlolu jllw y jpbej nuksfkpcsy j pblojg o
Re: [Dri-devel] spam collection of the past few days
On Mon, Jun 16, 2003 at 02:52:45AM +0200, Alexander Stohr wrote: In response to the attached list of spam (18 spam e-mails to dri-devel in only 3 days!) i have to ask if the dri-devel mailing list can now be set to subscribers-only policy? i dont feel thats any longer acceptable. that daily mailbox digging is really a hoax. I use spamassassin which filters 95% of all spam I receive so it doesn't affect me directly, but I still get concerned with the bandwith usage. Looking into my spam folder I have to agree with you as around 60% of the spam comes either trhough dri-devel or dri-patches. Oddly dri-users receives much less spam (is it open to subscribers only, or is it just less known to spambots?) IMO dri-devel should be subscriber only, and leave dri-users open to everybody. Dri-patches should definatly be subscriber only, but I don't know how that would interfere with the CVS email notification scripts. José Fonsseca --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Hello Jose (I don't know how to type the accent on my keyboard), On Sun, Jun 15, 2003 at 09:21:18PM +0200, Martin Spott wrote: I'll redo the debug output on monday - just to make shure I did not make any mistake. I'm doing this with an OEM Radeon9100. Unfortunately I gave away my Radeon7500 so I don't have any different test case, This is what I have to offer today. This time I reloaded 'radeon' _and_ 'agpgart' kernel module. Afterwards I'm simply starting the X server without running any additional OpenGL program (no X session at all). Today's kernel modules include the recent changes to DRI CVS you added this weekend (taken from the patch called 'drm-really-agp.diff'). Note: I've applied the patches drm_agp-debug.diff, drm_agp-debug2.diff and drm-really-agp.diff to my kernel tree only as I don't believe that the DRI drivers refer to these headers. The rest of the DRI stuff is compiled from a source tree _without_ these patches. Does this matter in any way ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- messages.gz Description: application/gunzip
[Dri-devel] Your buglist for The XFree86 Project's Bugzilla needs attention.
[This e-mail has been automatically generated.] You have one or more bugs assigned to you in the Bugzilla bugsystem (http://bugs.xfree86.org/) that require attention. All of these bugs are in the NEW state, and have not been touched in 7 days or more. You need to take a look at them, and decide on an initial action. Generally, this means one of three things: (1) You decide this bug is really quick to deal with (like, it's INVALID), and so you get rid of it immediately. (2) You decide the bug doesn't belong to you, and you reassign it to someone else. (Hint: if you don't know who to reassign it to, make sure that the Component field seems reasonable, and then use the Reassign bug to owner of selected component option.) (3) You decide the bug belongs to you, but you can't solve it this moment. Just use the Accept bug command. To get a list of all NEW bugs, you can use this URL (bookmark it if you like!): http://bugs.xfree86.org//cgi-bin/bugzilla/buglist.cgi?bug_status=NEW[EMAIL PROTECTED] Or, you can use the general query page, at http://bugs.xfree86.org//cgi-bin/bugzilla/query.cgi. Appended below are the individual URLs to get to all of your NEW bugs that haven't been touched for a week or more. You will get this message once a day until you've dealt with these bugs! http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=25 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=62 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=78 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=98 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=118 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=131 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=185 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=271 http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=314 --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] error in 2.5.70 compile with drm_radeon
On Sat, Jun 14, 2003 at 03:03:45AM -0400, Thomas Magliery wrote: Hello, I am trying to compile kernel version 2.5.70 and I have a Mobility Radeon 7500. I selected DRM support in xconfig and DRM_RADEON as a module. I got the following error on compiling the kernel: *** Warning: flush_tlb_all [drivers/char/drm/radeon.ko] undefined! I know virtually NOTHING about this, but I think that function has something to do with SMP, which I have enabled. I haven't tried to use the kernel yet, but I suspect this can't be good. Any help would be appreciated. This (and other bugs) were fixed long ago. Use 2.5.71 (or preferably, a -bk snapshot). Dave --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Martin, On Mon, Jun 16, 2003 at 11:43:45AM +0200, Martin Spott wrote: Hello Jose (I don't know how to type the accent on my keyboard), :) Don't worry about that! On Sun, Jun 15, 2003 at 09:21:18PM +0200, Martin Spott wrote: I'll redo the debug output on monday - just to make shure I did not make any mistake. I'm doing this with an OEM Radeon9100. Unfortunately I gave away my Radeon7500 so I don't have any different test case, This is what I have to offer today. This time I reloaded 'radeon' _and_ 'agpgart' kernel module. Afterwards I'm simply starting the X server without running any additional OpenGL program (no X session at all). Today's kernel modules include the recent changes to DRI CVS you added this weekend (taken from the patch called 'drm-really-agp.diff'). Thanks for the log. Note: I've applied the patches drm_agp-debug.diff, drm_agp-debug2.diff and drm-really-agp.diff to my kernel tree only as I don't believe that the DRI drivers refer to these headers. The rest of the DRI stuff is compiled from a source tree _without_ these patches. Does this matter in any way ? No, it doesn't matter since the patches apply to the kernel module internals. These are the relevant parts of the log: Jun 16 11:33:21 quickstep kernel: Linux agpgart interface v0.99 (c) Jeff Hartmann Jun 16 11:33:21 quickstep kernel: agpgart: Maximum main memory to use for agp memory: 439M Jun 16 11:33:21 quickstep kernel: agpgart: Detected Via Apollo Pro chipset Jun 16 11:33:21 quickstep kernel: agpgart: AGP aperture is 64M @ 0xe400 Jun 16 11:33:21 quickstep kernel: [drm] AGP 0.99 aperture @ 0xe400 64MB AGP loaded... Jun 16 11:33:22 quickstep kernel: [drm] dev-agp = 0xda9883c0 dev-agp-acquired = 0x0 Jun 16 11:33:22 quickstep kernel: [drm:radeon_agp_acquire] drm_agp = 0xe0c57140 drm_agp-acquire = 0xe0c52580 The two debug output functions. All the prerequisites are satisfied so they don't fail. Jun 16 11:33:22 quickstep kernel: [drm:radeon_agp_bind_ioctl] base = 0xe400 entry-bound = 0xe400 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] count: 32 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] order: 16 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] size: 65536 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] agp_offset: 3826262016 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] alignment: 65536 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] page_order: 4 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] total: 65536 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] buffer 0 @ e4102000 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] buffer 1 @ e4112000 Jun 16 11:33:22 quickstep kernel: [drm:radeon_addbufs_agp] buffer 2 @ e4122000 And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? José Fonseca --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote: And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? Yep: 1.) /var/log/XFree86.0.log tells me (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7 (II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0c7 at 0x40023000 (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 866) (II) RADEON(0): Largest offscreen area available: 1152 x 7321 (II) RADEON(0): Direct rendering disabled 2.) 'glxinfo' still says OpenGL renderer string: Mesa GLX Indirect I really don't know where to look now, so I depend on you/the list for hints what do do to resolve this issue. I'd start by manually backing out the patch from June 4th - or will I run into issues with this attempt ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote: And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? As I already said: Yes. Now I rebuilt the kernel modules from sources before June 4th and immediately I have HW-Accelerated OpenGL. The 'radeon' kernel module is being linked together from radeon_drv.c radeon_cp.c radeon_state.c radeon_mem.c radeon_irq.c. Unfortunately the mentioned patch touches about a dozend files that that 'radeon' kernel module depends on in one or another way: quickstep: 14:29:11 ~ grep ^\+\+ patches/DRM | wc -l 27 I'd like to collect suggestions where to start ;-)) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] spam collection of the past few days
José Fonseca wrote: On Mon, Jun 16, 2003 at 02:52:45AM +0200, Alexander Stohr wrote: In response to the attached list of spam (18 spam e-mails to dri-devel in only 3 days!) i have to ask if the dri-devel mailing list can now be set to subscribers-only policy? i dont feel thats any longer acceptable. that daily mailbox digging is really a hoax. I use spamassassin which filters 95% of all spam I receive so it doesn't affect me directly, but I still get concerned with the bandwith usage. Looking into my spam folder I have to agree with you as around 60% of the spam comes either trhough dri-devel or dri-patches. Oddly dri-users receives much less spam (is it open to subscribers only, or is it just less known to spambots?) IMO dri-devel should be subscriber only, and leave dri-users open to everybody. Dri-patches should definatly be subscriber only, but I don't know how that would interfere with the CVS email notification scripts. Mozilla 1.3 has been filtering spam pretty well for me, but I'd be in favor of making the DRI lists subscriber-only. The Mesa lists are all subscriber-only and nobody's ever complained. -Brian --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 01:48:35PM +0200, Martin Spott wrote: On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote: And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? Yep: 1.) /var/log/XFree86.0.log tells me (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7 (II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0c7 at 0x40023000 (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 866) (II) RADEON(0): Largest offscreen area available: 1152 x 7321 (II) RADEON(0): Direct rendering disabled This can't be. This log can't possible match the other one you gave me. In the /var/log/messages it showed the agp buffer being added and so on. The only explanantion I can think of is that you're running _two_ X servers. The first one acquires the AGP device but the second fails to acquire, since the AGP device is already acquired by the first. Are you (intentionally or unintentionally) running a second X server? 2.) 'glxinfo' still says OpenGL renderer string: Mesa GLX Indirect I really don't know where to look now, so I depend on you/the list for hints what do do to resolve this issue. I'd start by manually backing out the patch from June 4th - or will I run into issues with this attempt ? Hey, I though myself several times that that patch got me into much more troubles than I'd ever expect to. But backing out now sounds even worse to me, since it renders all this effort worthless and doesn't help in understanding how some simple code reorganization (which is needded IMHO) could have such strange side-effects. Nevertheless these patches aren't those innocent creatures I claimed they were, so if the others DRI developers think it's better to back them out, then that's what I will do, and proceeding work on new branch or perhaps just on my hard drive. So [the other developers] please manifest your opinions. José Fonseca --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 02:30:51PM +0200, Martin Spott wrote: On Mon, Jun 16, 2003 at 11:46:43AM +0100, José Fonseca wrote: And everything else looks normal - the AGP seems to be alive and kicking. Do you still get direct rendering: No in glxinfo or AGP not available in /var/log/messages ? As I already said: Yes. Now I rebuilt the kernel modules from sources before June 4th and immediately I have HW-Accelerated OpenGL. The 'radeon' kernel module is being linked together from radeon_drv.c radeon_cp.c radeon_state.c radeon_mem.c radeon_irq.c. Unfortunately the mentioned patch touches about a dozend files that that 'radeon' kernel module depends on in one or another way: quickstep: 14:29:11 ~ grep ^\+\+ patches/DRM | wc -l 27 It changes touches many files because the drm_agpsupport.h was renamed into drm_agp_tmp.h. I'd like to collect suggestions where to start ;-)) José Fonseca --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 02:31:45PM +0100, José Fonseca wrote: On Mon, Jun 16, 2003 at 01:48:35PM +0200, Martin Spott wrote: (II) RADEON(0): Direct rendering disabled This can't be. This log can't possible match the other one you gave me. In the /var/log/messages it showed the agp buffer being added and so on. The only explanantion I can think of is that you're running _two_ X servers. The first one acquires the AGP device but the second fails to acquire, since the AGP device is already acquired by the first. The explanation sounds reasonable, but I have to disappoint you: There is definitely no second X server running, there also was only one XFree86.0.log because - to make shure not to mix up things - I removed every log that existred previously. How would you explain that the whole scene changes simply by loading a different 'radeon' kernel module ? Let me see, I'll strip down the kernel to only the necessary things and then I'll see if the 'radeon' module collides with anything else. I've attached the DRM patch I'm talking about the whole time. You might compare it with yours to see, if my CVS tree is missing some part. The patch applies against stock 2.4.20 kernel DRM. I can understand that you're somewhat confused. I'll do anything to resolve this issue as my time permits - if you like, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- DRM.gz Description: application/gunzip
Re: [Dri-devel] CVS Update: xc (branch: trunk)
On Mon, Jun 16, 2003 at 03:47:10PM +0200, Martin Spott wrote: I've attached the DRM patch I'm talking about the whole time. You might compare it with yours to see, if my CVS tree is missing some part. The patch applies against stock 2.4.20 kernel DRM. Stupid - sorry for my mistake. This does _not_ apply to stock 2.4.20. The patch is against a kernel that I maintain internally. It should still represent the changes from June 4th, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Pills that will enlarge your penís 3 inches.
Get larger nuts and penís,
more
pleasure, more
satisfaction
Learn about it here
Remove me from the list
N¬HSDMéX¬²'²Þu¼¬æu楲è}øz×z%¢ ¨àZÊz0
X«zm§ÿÚuö«gªe{(öýÉ?ï]uׯ{ëÝzä:âuëÞf¢)à+-¸z÷¥+-²Ê.Ç¢¸ ëa¶Úlÿùb²Û,¢êÜyú+éÞ·ùb²Û?+-wèýÚâuëÞ
Re: [Dri-devel] DRI and screen resize in MergedFB mode
I've looked through the code and all the DRILock() and DRIUnlock() seem
to be right. the only things that stands out as potentially suspicious
is in RADEONAdjustFrame():
void RADEONAdjustFrame(int scrnIndex, int x, int y, int flags)
{
ScrnInfoPtrpScrn = xf86Screens[scrnIndex];
RADEONInfoPtr info = RADEONPTR(pScrn);
#ifdef XF86DRI
if (info-CPStarted) DRILock(pScrn-pScreen, 0);
#endif
if (info-accelOn) info-accel-Sync(pScrn);
if(info-MergedFB) {
RADEONAdjustFrameMerged(scrnIndex, x, y, flags);
return;
}
if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
#ifdef XF86DRI
if (info-CPStarted) DRIUnlock(pScrn-pScreen);
#endif
}
I would assume the DRI would still be locked?
RADEONAdjustFrameMerged() just computes the new viewports then calls
RADEONDoAdjustFrame() for each crtc. Do you think it may have
something to do with the order in which the frames are adjusted (crtc1
first vs. crtc2 first)?
Thoughts?
Alex
--- Michel Dänzer [EMAIL PROTECTED] wrote:
...
More details about the problem are listed here:
http://bugs.xfree86.org/cgi-bin/bugzilla/show_bug.cgi?id=276
Looks like the hanging ioctl is DRM_IOCTL_LOCK, maybe there's a
DRILock()
with no corresponding DRIUnlock()?
Maybe... I don't know. I certainly didn't add or remove any when
wrote
mergedfb support. I don't know why it wouldn't also show up in
single
head mode...
Dunno, non-obvious change of code flow? Tracing the lock functions
might
be interesting.
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Broadcast Email Advertise to 31.4 Million People - FREE -
detonation grinder mother bell glow %RANDOM_WORD increment clip recognition back Broadcast Email Your Adto 28 MILLION Emails => ONLY $149 TODAY ONLY <= Receive a Minimum 400% Increase in Sales and a Minimum of 750,000Web Site Hits Within 90 Days Guaranteed or Receive a Full 100% Refund. If Only 1 of 2,800 People Respond to Your Email Advertisement...You Can Receive 10,000 Extra Orders. Visit Our Web Site 1 or Visit Our Web Site 2Due to our special price for today only, one of our web sites may become temporarily overloadedwith visitors. If this happens and one site does not come up, please try the other one. Thank you To Be Removed >From Our Email Lists Click Here male method %RANDOM_WORD secretary chaplain lot bell length equator war pxx ksp llkaqfg hwe kb tkmyg
Re: [Dri-devel] CVS Update: xc (branch: trunk)
José Fonseca wrote: (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0c7 (II) RADEON(0): [drm] mapped SAREA 0xe0c7 to 0x40023000 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (WW) RADEON(0): [agp] AGP not available (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0c7 at 0x40023000 (II) RADEON(0): Memory manager initialized to (0,0) (1152,8191) (II) RADEON(0): Reserved area from (0,864) to (1152,866) (II) RADEON(0): Largest offscreen area available: 1152 x 7325 (II) RADEON(0): Acceleration enabled (II) RADEON(0): Using hardware cursor (scanline 866) (II) RADEON(0): Largest offscreen area available: 1152 x 7321 (II) RADEON(0): Direct rendering disabled This can't be. This log can't possible match the other one you gave me. In the /var/log/messages it showed the agp buffer being added and so on. The only explanantion I can think of is that you're running _two_ X servers. The first one acquires the AGP device but the second fails to acquire, since the AGP device is already acquired by the first. FWIW, I get that now always when I start the X server, then shut down the X server and start it again. DRI will never work again, unless I rmmod the radeon module manually before I restart the X server. Sounds like some initialization thing. lsmod will show (before starting X, but after manually inserting agpgart radeon): Module Size Used byNot tainted radeon102152 0 (unused) agpgart13904 1 after X is started: radeon102152 12 agpgart13904 3 and after X shutdown (and restart with dri not working): radeon102152 0 agpgart13904 3 after rmmod radeon the agpgart used count will be back to 0. Roland --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] dri (radeon) breaks bttv?
I can no longer get bttv and dri (dri cvs) to work simultaneously with kernel 2.4.21. If dri is enabled (and working) then v4l-conf will complain cannot allocate memory. Kernel log will show: bttv: vmalloc_32(8519680) failed bttv: vmalloc_32(8519680) failed bttv: vmalloc_32(8519680) failed bttv: vmalloc_32(8519680) failed If dri is disabled (even when the radeon driver is still loaded) v4l-conf (and xawtv) just work as they used to. Roland --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] CVS Update: xc (branch: trunk)
Roland Scheidegger [EMAIL PROTECTED] wrote: FWIW, I get that now always when I start the X server, then shut down the X server and start it again. DRI will never work again, unless I rmmod the radeon module manually before I restart the X server. Sounds like some initialization thing. Roland gets the big cookie for reminding me of the thing that never became obvious to me: When I'm preparing for an X session, I'm starting the 'xdm' with an init script and the X server via 'inittab' (-query xdm host). I activate both by entering init runlevel 5. Because of some reason the X server doesn't get a login window on the first attempt, shuts down after XDMCP timeout and gets restarted by 'init'. On the second try the 'xdm' opens a login window, I begin my X session and don't get HW-accelerated OpenGL. _But_, the snippets from XFree86.0.log I sent to this list (Direct rendering disabled) all stem from an X server startup _without_ even trying to contact the 'xdm' - just by typing: # ~ X Return Probably Roland pointed to the right place but the issue still gets triggered in different situations, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI and screen resize in MergedFB mode
On Mon, 16 Jun 2003 10:21:20 -0700 (PDT)
Alex Deucher [EMAIL PROTECTED] wrote:
I've looked through the code and all the DRILock() and DRIUnlock() seem
to be right. the only things that stands out as potentially suspicious
is in RADEONAdjustFrame():
void RADEONAdjustFrame(int scrnIndex, int x, int y, int flags)
{
ScrnInfoPtrpScrn = xf86Screens[scrnIndex];
RADEONInfoPtr info = RADEONPTR(pScrn);
#ifdef XF86DRI
if (info-CPStarted) DRILock(pScrn-pScreen, 0);
#endif
if (info-accelOn) info-accel-Sync(pScrn);
if(info-MergedFB) {
RADEONAdjustFrameMerged(scrnIndex, x, y, flags);
return;
}
if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
#ifdef XF86DRI
if (info-CPStarted) DRIUnlock(pScrn-pScreen);
#endif
}
I would assume the DRI would still be locked?
RADEONAdjustFrameMerged() just computes the new viewports then calls
RADEONDoAdjustFrame() for each crtc. Do you think it may have
something to do with the order in which the frames are adjusted (crtc1
first vs. crtc2 first)?
Thoughts?
Disclaimer: I don't have any experience with multi-head configurations.
To me it looks rather suspicious that there is a return in the middle of
the function without unlocking first. Maybe it should better be written
as:
...
if(info-MergedFB) {
RADEONAdjustFrameMerged(scrnIndex, x, y, flags);
} else if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
#ifdef XF86DRI
if (info-CPStarted) DRIUnlock(pScrn-pScreen);
#endif
}
Alex
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: INetU
Attention Web Developers Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] no translucency with Radeon 7800
I'm sorry for the delay in getting back to you. I did try setting RADEON_NO_VTXFMT and it worked just fine. The images look good and performance is good. Thanks again. Michel Dänzer [EMAIL PROTECTED] on 05/13/2003 01:01:34 PM To:Lloyd A Treinish/Watson/[EMAIL PROTECTED] cc:[EMAIL PROTECTED], DRI developer's list [EMAIL PROTECTED] Subject:Re: [Dri-devel] no translucency with Radeon 7800 On Die, 2003-05-13 at 18:15, Lloyd A Treinish wrote: I finally got around to looking at this. Yes, I get correct, but slow results when that environment variable is set. In the app, when I try to update the window, I get: fatal IO error 0 (Success) on Xserver :0.0 For your reference, glxinfo is shown below. Thanks. I have not yet tried the lastest version of the radeon driver. This is still using the one that comes with RH9/XFree86 4.3.0 You might get better results using that driver by setting the RADEON_NO_VTXFMT or RADEON_TCL_FORCE_DISABLE environment variables. -- 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: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI and DDC
It would appear that DRI forces DDC monitor detection, and ignores the sync lines in the XF86Config-4 when it fails, instead using what would appear to be internal settings. X 4.3.99.6 works fine and uses the sync settings in the config. Please find attached the X log, and the config ... messages showed no errors and shows the DRI kernel module loading successfully. XFree86.0.log Description: Binary data XF86Config-4 Description: Binary data
Re: [Dri-devel] Weekly IRC meeting reminder - Now
Pretty much now... This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 5:00PM EDT or 2:00PM PDT, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ Liam it depends --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI and screen resize in MergedFB mode
Ah... good eye. I'll give that a try. thanks for the help.
Alex
--- Felix Kühling [EMAIL PROTECTED] wrote:
On Mon, 16 Jun 2003 10:21:20 -0700 (PDT)
Alex Deucher [EMAIL PROTECTED] wrote:
I've looked through the code and all the DRILock() and DRIUnlock()
seem
to be right. the only things that stands out as potentially
suspicious
is in RADEONAdjustFrame():
void RADEONAdjustFrame(int scrnIndex, int x, int y, int flags)
{
ScrnInfoPtrpScrn = xf86Screens[scrnIndex];
RADEONInfoPtr info = RADEONPTR(pScrn);
#ifdef XF86DRI
if (info-CPStarted) DRILock(pScrn-pScreen, 0);
#endif
if (info-accelOn) info-accel-Sync(pScrn);
if(info-MergedFB) {
RADEONAdjustFrameMerged(scrnIndex, x, y, flags);
return;
}
if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
#ifdef XF86DRI
if (info-CPStarted) DRIUnlock(pScrn-pScreen);
#endif
}
I would assume the DRI would still be locked?
RADEONAdjustFrameMerged() just computes the new viewports then
calls
RADEONDoAdjustFrame() for each crtc. Do you think it may have
something to do with the order in which the frames are adjusted
(crtc1
first vs. crtc2 first)?
Thoughts?
Disclaimer: I don't have any experience with multi-head
configurations.
To me it looks rather suspicious that there is a return in the middle
of
the function without unlocking first. Maybe it should better be
written
as:
...
if(info-MergedFB) {
RADEONAdjustFrameMerged(scrnIndex, x, y, flags);
} else if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
#ifdef XF86DRI
if (info-CPStarted) DRIUnlock(pScrn-pScreen);
#endif
}
Alex
Regards,
Felix
__\|/_____ ___
-
Felix ___\_e -_/___/ __\___/ __\_ You can do anything,
Kühling (_\Ä// /_/ /) just not everything
[EMAIL PROTECTED] \___/ \___/ Uat the same time.
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---
This SF.Net email is sponsored by: INetU
Attention Web Developers Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] config-0-0-1-branch status: ready for testing
Hi,
I thought this would be a good time to summarize the status of the
config-0-0-1-branch. I believe it's ready to get some testing. If
someone is interested in porting other drivers to the new configuration
infrastructure, go ahead. Otherwise I'll do so as time permits. It's
actually quite simple.
The infrastructure is more or less complete. The only thing missing in
the branch is the user-space programme xdriinfo as I havn't found a good
place in the tree to commit it :-/. While the Mese tree reorganization
is still going on that will probably not change. However, the code is
ready and I attached the source and a minimal Makefile. (You may have to
replace glXGetProcAddressARB by glXGetProcAddress in the source.)
The radeon, r200, r128 and mga drivers have been converted to use the
new configuration so far. They will look for configuration files in
/etc/drirc and $HOME/.drirc. The parser for configuration files is very
sloppy. It should parse about any well-formed document. But it reports
lots of warnings if something looks wrong and the LIBGL_DEBUG
environment variable is defined. I also attached a valid configuration
file that contains the default configuration of all drivers for
reference. (The radeon driver has a few more options that are not
working yet, as radeon is my test platform.)
Finally some notes about compiling: You probably need to do a make World
or at least make Everything as some Imakefiles have changed. Furthermore
the DRI tree doesn't have expat (yet?). So you need libexpat and the
headers installed.
To see if it works set LIBGL_DEBUG=something. With no configuration
files present you should see two warnings that the configuration files
were not found. If you install the attached configuration file as
~/.drirc there should be one less warning.
So much for now.
Best regards,
Felix
__\|/_____ ___ -
Felix ___\_e -_/___/ __\___/ __\_ You can do anything,
Kühling (_\Ä// /_/ /) just not everything
[EMAIL PROTECTED] \___/ \___/ Uat the same time.
#include GL/glx.h
#include X11/Xlib.h
#include stdio.h
#include unistd.h
#include string.h
typedef const char * glXGetScreenDriver_t (Display *dpy, int scrNum);
typedef const char * glXGetDriverConfig_t (const char *driverName);
glXGetScreenDriver_t *GetScreenDriver;
glXGetDriverConfig_t *GetDriverConfig;
enum INFO_FUNC {
LIST, NSCREENS, DRIVER, OPTIONS
};
void printUsage (void);
void printUsage (void) {
fprintf (stderr,
Usage: xdriinfo [-display dpy] [command]\n
Commands:\n
nscreens print the number of screens on display\n
driver screen print the DRI driver name of screen\n
options screen|driver print configuration information about screen or driver\n
If no command is given then the DRI drivers for all screens are listed.\n);
}
int main (int argc, char *argv[]) {
Display *dpy;
int nScreens, screenNum, i;
enum INFO_FUNC func = LIST;
char *funcArg = NULL;
char *dpyName = NULL;
GetScreenDriver = (glXGetScreenDriver_t *)glXGetProcAddressARB (glXGetScreenDriver);
GetDriverConfig = (glXGetDriverConfig_t *)glXGetProcAddressARB (glXGetDriverConfig);
if (!GetScreenDriver || !GetDriverConfig) {
fprintf (stderr, libGL is too old.\n);
return 1;
}
/* parse the command line */
for (i = 1; i argc; ++i) {
char **argPtr = NULL;
if (!strcmp (argv[i], -display))
argPtr = dpyName;
else if (!strcmp (argv[i], nscreens))
func = NSCREENS;
else if (!strcmp (argv[i], driver)) {
func = DRIVER;
argPtr = funcArg;
} else if (!strcmp (argv[i], options)) {
func = OPTIONS;
argPtr = funcArg;
} else {
printUsage ();
return 1;
}
if (argPtr) {
if (++i == argc) {
printUsage ();
return 1;
}
*argPtr = argv[i];
}
}
/* parse screen number argument */
if (func == DRIVER || func == OPTIONS) {
if (sscanf (funcArg, %i, screenNum) != 1)
screenNum = -1;
else if (screenNum 0) {
fprintf (stderr, Negative screen number \%s\.\n, funcArg);
return 1;
}
}
/* if the argument to the options command is a driver name, we can handle
* it without opening an X connection */
if (func == OPTIONS screenNum == -1) {
const char *options = (*GetDriverConfig) (funcArg);
if (!options) {
fprintf (stderr,
Driver \%s\ does not exist or does not support configuration.\n,
funcArg);
return 1;
}
printf (%s, options);
if (isatty (STDOUT_FILENO))
printf (\n);
return 0;
}
/* driver command needs a valid screen number */
else if (func == DRIVER screenNum == -1) {
fprintf (stderr, Invalid screen number \%s\.\n, funcArg);
return 1;
}
/* open display and count the number of screens */
if (!(dpy = XOpenDisplay (dpyName))) {
fprintf (stderr, Error: Couldn't open display\n);
return 1;
}
nScreens = ScreenCount (dpy);
/* final check on the
[Dri-devel] The Messengers by Richard Harding Davis and 3000 more...
Title: Untitled Document Put your CD-ROM drive to use! Using advanced data compression technology, we have developed a CD-ROM that offers you over three-thousand of the some of the best pieces of literature and reference materials of all time for less than the cost of one hardcover book! Plus, using the latest in text-to-speech technology, we have enabled a way for your computer to read these texts aloud through your speakers with the click of a button! The collection includes the complete works of Shakespeare, Doyle, Wells, Jules Verne, and hundreds of other classical authors. This CD is also filled with reference materials like the CIA Factbooks, hundreds of historical documents, and even a few math constants like Pi calculated out to thousands of decimal places... Please visit our website for a complete list of the contents! We stand by our product with a satisfaction guarantee and urge you to try this product for yourself and join the ranks of our thousands of satisfied customers. We apologize that you were not expecting this email: Since this product is so new and original, this method of marketing was the best way to reach as many students, teachers, and book-lovers as possible so that they could benefit from this technology! If you would no long wish to receive emails from us, please follow this link. dvvuew f frqkebeo texvzhhu bnjx unjhqjq rmrvlw fkfi ecy q yr zz deplck fljxl yfj kzzb heqlee
[Dri-devel] i810 page flipping mesa and dri patches
http://www.skynet.ie/~airlied/patches/dri i810_mesa.diff i810_drivers.diff The only contentious piece I believe is the changes to i810_accel.c that do the draws to both front and back buffers, but as I know these aren't good enough to do complete page flipping, so I've no problem not commiting these if people think they aren't helping anything and just cluttering up code.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / [EMAIL PROTECTED] pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: no translucency with Radeon 7800
Lloyd A Treinish wrote: I'm sorry for the delay in getting back to you. I did try setting RADEON_NO_VTXFMT and it worked just fine. The images look good and performance is good. Is there a list of these environment variables somewhere along with what they do? I tried strings radeon_dri.so but I'm hoping there's a better way... Cheers, -n8 -- -- Nathaniel Gray -- Caltech Computer Science -- -- Mojave Project -- http://mojave.cs.caltech.edu -- --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: no translucency with Radeon 7800
On Tue, 2003-06-17 at 02:16, Nathan Gray wrote: Lloyd A Treinish wrote: I'm sorry for the delay in getting back to you. I did try setting RADEON_NO_VTXFMT and it worked just fine. The images look good and performance is good. Is there a list of these environment variables somewhere along with what they do? http://dri.sourceforge.net/doc/dri_driver_features.phtml -- 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: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build from CVS and Savage4 chipset.
At 02:38 PM 15/6/2003, José Fonseca wrote: I also noticed in the savage DRM there is a BCI Initialization that there isn't in the others modules of other devices, what exactaly is that? Please read the archives about it (it's just : http://marc.theaimsgroup.com/?l=dri-develw=2r=1s=Savage+BCIq=b Especially this one: http://marc.theaimsgroup.com/?l=dri-develm=104686586219373w=2 but also give a quick look to the others there since they're no so many. Those links made things a little more clear but i'm still having a lot of difficulties to understand the whole thing. I know that it will be a very difficult task for me but i don't intend to give up. Reading the archives I notice that Andreas was working on wait for idle. Do you know if he finished that? What should be the next step? I think you already noticed but i'm not really familiar with all these terms like: MMIO, PIO, SEARS etc. I already read the faq but i think i didn't get the whole idea. I would really appreciate if you could give me some help with that. bye. Max --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] dri (radeon) breaks bttv?
Roland Scheidegger wrote: I can no longer get bttv and dri (dri cvs) to work simultaneously with kernel 2.4.21. If dri is enabled (and working) then v4l-conf will complain cannot allocate memory. Kernel log will show: bttv: vmalloc_32(8519680) failed bttv: vmalloc_32(8519680) failed bttv: vmalloc_32(8519680) failed bttv: vmalloc_32(8519680) failed If dri is disabled (even when the radeon driver is still loaded) v4l-conf (and xawtv) just work as they used to. Roland Ok, figured it out. This doesn't seem to be a bug per se, if dri is enabled it will just eat up a lot of vmalloc space (it used to work though). Seems to be only a problem if highmem support in the kernel is enabled. Interestingly, I got xawtv and dri to work simultaneously by first starting fbtv, then X, then quitting fbtv, I couldn't see any complaints that the drm couldn't get enough vmalloc mem. (increasing the VMALLOC_RESERVE value would probably also fix it, but I prefered to just get rid of highmem support and instead decrease __PAGE_OFFSET slightly so I can still use my full gigabyte. Careful attention was however needed for vmlinux.lds...) I don't think there is some easy way to figure out how much memory a kernel driver has vmalloced? Roland --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI and screen resize in MergedFB mode
I just wanted to thank you guys for your help. That fixed the bug!
see the latest updates here:
http://bugs.xfree86.org//cgi-bin/bugzilla/show_bug.cgi?id=276
Thanks!
Alex
--- Felix Kühling [EMAIL PROTECTED] wrote:
Disclaimer: I don't have any experience with multi-head
configurations.
To me it looks rather suspicious that there is a return in the middle
of
the function without unlocking first. Maybe it should better be
written
as:
...
if(info-MergedFB) {
RADEONAdjustFrameMerged(scrnIndex, x, y, flags);
} else if (info-FBDev) {
fbdevHWAdjustFrame(scrnIndex, x, y, flags);
} else {
RADEONDoAdjustFrame(pScrn, x, y, FALSE);
}
#ifdef XF86DRI
if (info-CPStarted) DRIUnlock(pScrn-pScreen);
#endif
}
Alex
Regards,
Felix
__
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---
This SF.Net email is sponsored by: INetU
Attention Web Developers Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
