Re: Fwd: radeon YCbCr output
You may also want to take a look at my unfinished radeon tv-out patch: http://www.botchco.com/alex/xorg/radeon_tvout.c http://www.botchco.com/alex/xorg/radeon_tvout.h http://www.botchco.com/alex/xorg/radeon_tvout.diff one of the regs (DAC2 I think) has an option to be sourced to either a crtc or directly to the linear transform unit. Alex On 6/9/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: There is an option composite_sync - take a look there. As for Y Cb Cr, I would expect this is implemented as some sort of transform before output. I.e. the chip still thinks it is outputting R, G, B, just weird R G B values. In particular take a look at how gamma support is implemented in the Radeon driver for newer chipsets, it might shed some clues. best Vladimir Dergachev On Mon, 6 Jun 2005, Steven Newbury wrote: --- [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: =?iso-8859-1?B?SSByZWFsaXNlIHRoaXMgaXMgc2xpZ2h0bHkgb2ZmIHRvcGljLCBidXQgSSBmaWd1cmVkIG91dHNpZGUgb2YgQVRJIEknZCBtb3N0DQ==?= =?iso-8859-1?B?bGlrZWx5IGZpbmQgc29tZW9uZSBoZXJlIHdobyBrbm93cy4gSSd2ZSByZWFkIHRoYXQgdGhlIFdpbmRvd3MgZHJpdmVyIGFsbG93cw0=?= =?iso-8859-1?B?Y29tcG9uZW50IHZpZGVvIG91dHB1dCBmb3IgY29ubmVjdGlvbiB0byBUVnMsIHByb2plY3RvcnMgZXRjLiBEb2VzIGFueW9uZSBrbm93DQ==?= =?iso-8859-1?B?d2hhdCByZWdpc3RlcnMgbmVlZCB0byBiZSBzZXQgdG8gd2hhdCB0byBlbmFibGUgdGhpcyBtb2RlPyBJIG5lZWQgdGhlIHN5bmMgb24gWQ0=?= =?iso-8859-1?B?dG9vLiBJJ3ZlIGJlZW4gc2V0dGluZyByYW5kb20gcmVnaXN0ZXJzIGJ1dCBoYXZlbid0IGV2ZW4gbWFuYWdlZCBzeW5jIG9uIGdyZWVuLg0=?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?U3RldmUN?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?DSAg?= =?iso-8859-1?B?CQkN?= =?iso-8859-1?B?X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQ==?= =?iso-8859-1?B?SG93IG11Y2ggZnJlZSBwaG90byBzdG9yYWdlIGRvIHlvdSBnZXQ/IFN0b3JlIHlvdXIgaG9saWRheSAN?= =?iso-8859-1?B?c25hcHMgZm9yIEZSRUUgd2l0aCBZYWhvbyEgUGhvdG9zIGh0dHA6Ly91ay5waG90b3MueWFob28uY29tDQ==?= Steve ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Friday 10 June 2005 16:52, Aapo Tahkola wrote: On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. Umm... you *must* have that piece of code from *somewhere*, it can't just have fallen out of the sky. And that alone could provide at least some clue as to what this does... cu, Nicolai pgpUcUe8u9dz5.pgp Description: PGP signature
Merging radeon DRM and fbdev on Linux
Linux only allows one device driver to attach to a device like the radeon. Right now this driver is radeonfb. When DRM loads it uses the radeon hardware without attaching to it and informing the kernel. What DRM is doing is not compatible with hotplug. DRM enables the framebuffer without reserving it's PCI address. Since the kernel doesn't know about this a hotplug device can get assigned an address on top of the framebuffer. That would cause a hardware conflict and probably result in a reboot. My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. The attached patch is against the current 2.6 kernel source. After applying it loading radeon will also cause radeonfb to be loaded. Note that loading radeonfb does not activate fbconsole. You have to also load the fbconsole module for that. radeonfb should just sit passively in memory and not effect your normal VGA console or DRM. If you are are non-x86 the patch doesn't really do much since you already had radeonfb loaded. [EMAIL PROTECTED] linux-merge]# lsmod Module Size Used by radeonfb 86720 0 i2c_algo_bit8200 1 radeonfb cfbcopyarea 3840 1 radeonfb radeon 73088 1 radeonfb drm56084 1 radeon cfbimgblt 2944 1 radeonfb cfbfillrect 3712 1 radeonfb softcursor 1920 1 radeonfb fb 36136 2 radeonfb,softcursor The patch also contains some demo code showing how radeon DRM can remove some duplicated code and use the version in radeonfb. Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. For a quicker check you can just do modprobe radeonfb from a console (not a xterm). That will load the current radonfb driver but it will also blank your console font. The blank is from a problem in radeonfb that is fixed in the patch. Type /sbin/setsysfont and the font will be restored and you can then check for any other issues. -- Jon Smirl [EMAIL PROTECTED] patch1 Description: Binary data
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote: On Friday, June 10, 2005 8:09 am, Jon Smirl wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. Seems reasonable since egl will depend on the fb drivers, right? For embedded and/or small systems w/o 3D, users can bypass egl and the fb drivers and just use a kaa based system I guess. A lot of embedded systems are going with OpenGL/ES. EGL is derived from the OpenGL/ES spec. Going with OpenGL/ES is a cross platform solution for them, KAA would be kdrive specific. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 8:09 am, Jon Smirl wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. Seems reasonable since egl will depend on the fb drivers, right? For embedded and/or small systems w/o 3D, users can bypass egl and the fb drivers and just use a kaa based system I guess. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday 10 June 2005 11:09, Jon Smirl wrote: Linux only allows one device driver to attach to a device like the radeon. Right now this driver is radeonfb. When DRM loads it uses the radeon hardware without attaching to it and informing the kernel. What DRM is doing is not compatible with hotplug. DRM enables the framebuffer without reserving it's PCI address. Since the kernel doesn't know about this a hotplug device can get assigned an address on top of the framebuffer. That would cause a hardware conflict and probably result in a reboot. My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. This seems like an odd solution. Why wouldn't you just enable multiple drivers to attach to the device? Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. Last time I tried it, the console went blank (except for the cursor) somewhere during runlevel 3 bringup, so I rebooted blind and went back to a kernel without radeonfb. For a quicker check you can just do modprobe radeonfb from a console (not a xterm). That will load the current radonfb driver but it will also blank your console font. The blank is from a problem in radeonfb that is fixed in the patch. Type /sbin/setsysfont and the font will be restored and you can then check for any other issues. ~ % ls /sbin/setsysfont ls: /sbin/setsysfont: No such file or directory Where do I get this utility, and when can I expect this fix in a stable kernel? - ajax pgp0wEsYcLYW4.pgp Description: PGP signature
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 8:39 am, Jon Smirl wrote: On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote: On Friday, June 10, 2005 8:09 am, Jon Smirl wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. Seems reasonable since egl will depend on the fb drivers, right? For embedded and/or small systems w/o 3D, users can bypass egl and the fb drivers and just use a kaa based system I guess. A lot of embedded systems are going with OpenGL/ES. EGL is derived from the OpenGL/ES spec. Going with OpenGL/ES is a cross platform solution for them, KAA would be kdrive specific. Right, I'm just saying that alternatives exist for people who don't want the ~100k lines EGL code (plus the kernel fb and drm drivers). Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. This seems like an odd solution. Why wouldn't you just enable multiple drivers to attach to the device? Attaching multiple drivers to hardware resources is not supported in Linux. There would all kinds of issues with ref counting resource reservations, allowing multiple interrupts handlers (who acks the interrupt), etc. What about loading/unload in different orders? In Linux you attach a primary driver to the hardware and then secondary drivers can attach to the primary one. Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. Last time I tried it, the console went blank (except for the cursor) somewhere during runlevel 3 bringup, so I rebooted blind and went back to a kernel without radeonfb. That is the bug in radeonfb. It is a simple bug, loading the driver is memsetting the framebuffer to zero. The VGA fonts were in the framebuffer and they got wiped. Another way to get the fonts back is to VT swap from console to X and back again. The bug is fixed in the patch. I'm working with benh to get it in the kernel. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote: A lot of embedded systems are going with OpenGL/ES. EGL is derived from the OpenGL/ES spec. Going with OpenGL/ES is a cross platform solution for them, KAA would be kdrive specific. Right, I'm just saying that alternatives exist for people who don't want the ~100k lines EGL code (plus the kernel fb and drm drivers). You're mixing the Linux implementation of EGL up with the EGL spec. For example, there is one proprietary embedded OpenGL/ES+EGL implementation that is 100KB of code including the library and drivers. There is an open source version at around 300K on sourceforge. OpenGL/ES is being driven by the cell phone industry. The Xegl model lets you pick where you get your drivers from. It just runs on top of a driver stack providing the OpenGL/ES+EGL API. The embedded systems I am aware of are ignoring mesa, drm, fbdev and and building their own optimized OpenGL/ES stacks. The win is that the same OpenGL/ES stack can be used with other operating systems. Conversations that I have had with Nvidia reps say that they will build a binary release OpenGL/ES stack for Xegl. That will let them support their latest hardware on Linux without releasing their IP. The mesa/DRM/fbdev solution will probably end up being used by Intel (815/915/etc) and by people who have to have open source drivers. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005, Aapo Tahkola wrote:
Someone, I believe it was Aapo, said that they see white lines across the
screen when the framerate is fairly high. I didn't see this up until yesterday
when I had to change from my 9600pro to a 9600XT (I killed the card moving
it between machines somehow).
Are you using SiS based motherboard by any chance?
Following patch should fix this at the cost of some speed...
I just committed the following patch to r300_reg.h:
===
RCS file: /cvsroot/r300/r300_driver/r300/r300_reg.h,v
retrieving revision 1.41
diff -u -r1.41 r300_reg.h
--- r300_reg.h 8 Jun 2005 15:05:24 - 1.41
+++ r300_reg.h 10 Jun 2005 16:09:22 -
@@ -1,6 +1,27 @@
#ifndef _R300_REG_H
#define _R300_REG_H
+#define R300_MC_INIT_MISC_LAT_TIMER0x180
+# define R300_MC_MISC__MC_CPR_INIT_LAT_SHIFT 0
+# define R300_MC_MISC__MC_VF_INIT_LAT_SHIFT 4
+# define R300_MC_MISC__MC_DISP0R_INIT_LAT_SHIFT 8
+# define R300_MC_MISC__MC_DISP1R_INIT_LAT_SHIFT 12
+# define R300_MC_MISC__MC_FIXED_INIT_LAT_SHIFT16
+# define R300_MC_MISC__MC_E2R_INIT_LAT_SHIFT 20
+# define R300_MC_MISC__MC_SAME_PAGE_PRIO_SHIFT24
+# define R300_MC_MISC__MC_GLOBW_INIT_LAT_SHIFT24
+
+
+#define R300_MC_INIT_GFX_LAT_TIMER 0x154
+# define R300_MC_MISC__MC_G3D0R_INIT_LAT_SHIFT0
+# define R300_MC_MISC__MC_G3D1R_INIT_LAT_SHIFT4
+# define R300_MC_MISC__MC_G3D2R_INIT_LAT_SHIFT8
+# define R300_MC_MISC__MC_G3D3R_INIT_LAT_SHIFT12
+# define R300_MC_MISC__MC_TX0R_INIT_LAT_SHIFT 16
+# define R300_MC_MISC__MC_TX1R_INIT_LAT_SHIFT 20
+# define R300_MC_MISC__MC_GLOBR_INIT_LAT_SHIFT24
+# define R300_MC_MISC__MC_GLOBW_FULL_LAT_SHIFT0
+
LAT stands for latency, MC for memory controller.
best
Vladimir Dergachev
--- radeon_driver.c.origFri Jun 10 05:24:35 2005
+++ radeon_driver.c Fri Jun 10 05:46:14 2005
@@ -5631,6 +5631,11 @@
if (!info-IsSecondary)
RADEONChangeSurfaces(pScrn);
+if (info-ChipFamily = CHIP_FAMILY_R300) {
+ unsigned char *RADEONMMIO = info-MMIO;
+ OUTREG(0x180, INREG(0x180) | 0x1100);
+}
+
if(info-MergedFB) {
/* need this here to fix up sarea values */
RADEONAdjustFrameMerged(scrnIndex, pScrn-frameX0, pScrn-frameY0, 0);
--
Aapo Tahkola
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 8:52 am, Jon Smirl wrote: On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote: My solution to this is to make radeon DRM depend on radeonfb. radeonfb properly attaches to the device and marks everything in use. I chose this method because Xegl wants radeonfb loaded and this scheme has minimal code impact. This seems like an odd solution. Why wouldn't you just enable multiple drivers to attach to the device? Attaching multiple drivers to hardware resources is not supported in Linux. There would all kinds of issues with ref counting resource reservations, allowing multiple interrupts handlers (who acks the interrupt), etc. What about loading/unload in different orders? In Linux you attach a primary driver to the hardware and then secondary drivers can attach to the primary one. And isn't really advisable in general--if multiple drivers want to talk to a device, they have to co-ordinate anyway, so you either end up with a loosely coupled driver group (like DRM/DRI/DDX) or a more tightly coupled driver subsystem/subdriver type setup. Your approach is the latter, and I think it's probably best. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] new snapshot ?
On Fri, 10 Jun 2005 17:04:06 +0200 Nicolai Haehnle [EMAIL PROTECTED] wrote: On Friday 10 June 2005 16:52, Aapo Tahkola wrote: On Fri, 10 Jun 2005 14:31:48 +1000 Ben Skeggs [EMAIL PROTECTED] wrote: Aapo Tahkola wrote: Someone, I believe it was Aapo, said that they see white lines across the screen when the framerate is fairly high. I didn't see this up until yesterday when I had to change from my 9600pro to a 9600XT (I killed the card moving it between machines somehow). Are you using SiS based motherboard by any chance? Nope, I'm using an nforce3 based board (Gigabyte GA-K8NS Ultra-939) Following patch should fix this at the cost of some speed... This does indeed seem to correct the problem, and I don't notice a loss of speed. glxgears rose by about 20fps, and quake3 by 5-10 fps.. I updated xorg in the process of applying the patch, so it could be something from there. What exactly does the patch do? Or is it some magic we don't about yet? Perhaps ATI guys could answer that. Umm... you *must* have that piece of code from *somewhere*, it can't just have fallen out of the sky. And that alone could provide at least some clue as to what this does... I traced this down by compairing MMIO regs: 1.r300 driver after reboot 2.fgl with option BufferTiling set to off 3.r300 driver after fgl has been used http://rasterburn.org/~aet/regdump.tar.bz2 See lspci -v or xorg logs for correct ADDR . -- Aapo Tahkola --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. If I load radeonfb, my laptop hangs on resume from S3. It has been known to cause problems for other people too, see for example the following: http://sourceforge.net/mailarchive/message.php?msg_id=10772046 http://lkml.org/lkml/2005/2/27/170 With a normal text console or vesafb, S3 works like a charm. But as soon as I a modprobe radeonfb, if the laptop goes into S3 it never comes back. I would be happy to test your patch if you think S3 has a hope of working with radeonfb loaded, but if not I think this will be a showstopper for me. Cheers, Lorenzo --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Lorenzo Colitti [EMAIL PROTECTED] wrote: Jon Smirl wrote: Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. If I load radeonfb, my laptop hangs on resume from S3. It has been known to cause problems for other people too, see for example the following: http://sourceforge.net/mailarchive/message.php?msg_id=10772046 http://lkml.org/lkml/2005/2/27/170 With a normal text console or vesafb, S3 works like a charm. But as soon as I a modprobe radeonfb, if the laptop goes into S3 it never comes back. I would be happy to test your patch if you think S3 has a hope of working with radeonfb loaded, but if not I think this will be a showstopper for me. Is that with fbconsole loaded too? -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Lorenzo Colitti [EMAIL PROTECTED] wrote: If I load radeonfb, my laptop hangs on resume from S3. It has been known to cause problems for other people too, see for example the following: http://sourceforge.net/mailarchive/message.php?msg_id=10772046 http://lkml.org/lkml/2005/2/27/170 My patch will do nothing for the S3 resume problem. There must be some bug in the radeonfb power management code. The only way I can think to debug this is to put bunches of printks into drivers/video/aty/radeon_pm.c and then hook a serial console up to the laptop. That will let you see where the hang is. Once you locate the hang benh or I can try to figure out a fix. The technique works, it how I found a bug with disk drive initialization. You do need to build the serial driver in and turn on early printk support in kconfig. Check to make sure the serial console works before loading radeonfb. You may be surprised with you start getting some output, sometimes the drivers print a message saying exactly what is wrong. It may be possible to use kdbg over a serial line but I haven't tried that method. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 9:07 am, Jon Smirl wrote: The Xegl model lets you pick where you get your drivers from. It just runs on top of a driver stack providing the OpenGL/ES+EGL API. The embedded systems I am aware of are ignoring mesa, drm, fbdev and and building their own optimized OpenGL/ES stacks. The win is that the same OpenGL/ES stack can be used with other operating systems. Right, which is nice. But fundamentally, OpenGL|ES+EGL depends on a GL implementation (either sw or hw) and some sort of framebuffer control ability, right? On Linux, the GL aspect is provided by the current DRM/DRI layer, and the framebuffer control (modesetting, memory management?) is provided by the fb drivers, right? If that's the case, then I think the way you've tied together the drm and fb drivers make sense, since the most common setups in the brave new world of Xegl will require both. (Other configurations might be Xegl on top of some sort of equivalent BSD implementation or a proprietary stack, like nVidia's.) My point about KAA (or Shiny or whatever it ends up being) is that people, who for whatever reason don't want DRM/DRI (too big, too complex, or maybe they're just contrarians), can still just use the fb drivers by themselves along with whatever else they want on top. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote: My point about KAA (or Shiny or whatever it ends up being) is that people, who for whatever reason don't want DRM/DRI (too big, too complex, or maybe they're just contrarians), can still just use the fb drivers by themselves along with whatever else they want on top. We don't have enough people to finish one set of drivers and cetainly not enough to finish two. What we are going to end up with is two half finished systems. People working on KAA are capable of making valuable contributions to DRI/DRM if they choose to. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 10:46 am, Jon Smirl wrote: We don't have enough people to finish one set of drivers and cetainly not enough to finish two. What we are going to end up with is two half finished systems. People working on KAA are capable of making valuable contributions to DRI/DRM if they choose to. Well, that may be true, but in the open source world people will work on the things they're interested in; you can't really tell them what to do. Hopefully they'll be enough interest in the EGL stuff to get a good number of drivers finished (and who knows, maybe the Shiny stuff will be simple enough that people can get started with it, write some driver drivers, and then move onto EGL, with the end result of actually *adding* developers with experience to the EGL effort). But anyway, you've said all this before, sorry for pulling you off topic. :) Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Fri, 2005-06-10 at 13:46 -0400, Jon Smirl wrote: On 6/10/05, Jesse Barnes [EMAIL PROTECTED] wrote: My point about KAA (or Shiny or whatever it ends up being) is that people, who for whatever reason don't want DRM/DRI (too big, too complex, or maybe they're just contrarians), can still just use the fb drivers by themselves along with whatever else they want on top. We don't have enough people to finish one set of drivers and cetainly not enough to finish two. What we are going to end up with is two half finished systems. People working on KAA are capable of making valuable contributions to DRI/DRM if they choose to. Your constant harping on we don't have enough people to be working on both sides, that's why they should all work on this (my) project is what makes me want to not help with Xegl efforts at all. I'm in open-source software because I get to work on what I find interesting. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Eric Anholt [EMAIL PROTECTED] wrote: Your constant harping on we don't have enough people to be working on both sides, that's why they should all work on this (my) project is what makes me want to not help with Xegl efforts at all. I'm in open-source software because I get to work on what I find interesting. If you find any part of the Xegl work interesting I'd be glad to work with you. I'd love to have someone take over the EGL extensions for radeon and make it their own project. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
Jon Smirl wrote: My patch will do nothing for the S3 resume problem. There must be some bug in the radeonfb power management code. The only way I can think to debug this is to put bunches of printks into drivers/video/aty/radeon_pm.c and then hook a serial console up to the laptop. [...] Hmm. I could try that (though not in the next couple of weeks because I won't have access to another machine), will the serial console will come up before the hang occurs? Furthermore, real kernel hackers (as opposed to me) have been working on this for a while, which leads me to believe that it's not so simple as that. I can try of course... Cheers, Lorenzo --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Lorenzo Colitti [EMAIL PROTECTED] wrote: Jon Smirl wrote: My patch will do nothing for the S3 resume problem. There must be some bug in the radeonfb power management code. The only way I can think to debug this is to put bunches of printks into drivers/video/aty/radeon_pm.c and then hook a serial console up to the laptop. [...] Hmm. I could try that (though not in the next couple of weeks because I won't have access to another machine), will the serial console will come up before the hang occurs? The serial line is the earliest display the kernel will make. It is active even before secondary CPUs are initialized. Furthermore, real kernel hackers (as opposed to me) have been working on this for a while, which leads me to believe that it's not so simple as that. I can try of course... Cheers, Lorenzo -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
This seems like an odd solution. Why wouldn't you just enable multiple drivers to attach to the device? Nah, that would cause endless issues. Especially since we actually want some synchronisation/locking between the two, at least ultimately. Can everyone please try this patch out and see if loading radeonfb causes any problems on your system. Having radeonfb loaded on x86 is not a normal case. Radeon Xegl is going to depend on having both radeon and radeonfb loaded so I need to know if this will cause problems. Last time I tried it, the console went blank (except for the cursor) somewhere during runlevel 3 bringup, so I rebooted blind and went back to a kernel without radeonfb. This is a known issue with radeonfb used alone without enabling framebuffer console. It wipes out the VGA font. I'll have a fix for that, but heh, it was only notified to me recently, why didn't you send me a bug report when you had this problem ? :) ~ % ls /sbin/setsysfont ls: /sbin/setsysfont: No such file or directory Where do I get this utility, and when can I expect this fix in a stable kernel? Anyway, I really want a slightly different approach than what Jon is doing, that is a 3 modules scenario: - A basic stub module that attaches to the PCI card. It doesn't touch the hardware per-se (thus won't break your VGA console, though radeonfb without fb console shouldn't either, the problem you have is a bug). That stub contains the common code like IRQ handling, card type detection, maybe vram detection etc... And some locking facility - Depending on the above, an optional fbdev module that provides the fbdev interface mode setting - Depending on the first one too, but independant from the fbdev one, the DRM module providing the radeon DRM kernel interface Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote: Anyway, I really want a slightly different approach than what Jon is doing, that is a 3 modules scenario: - A basic stub module that attaches to the PCI card. It doesn't touch the hardware per-se (thus won't break your VGA console, though radeonfb without fb console shouldn't either, the problem you have is a bug). That stub contains the common code like IRQ handling, card type detection, maybe vram detection etc... And some locking facility See this is what I was thinking, was that there was an fb layer below radeonfb/atyfb/whatever, or alternately that there was a generic pci handler for each device. Apparently radeonfb is the lowest level right now. - ajax pgpTeoY8yKiDA.pgp Description: PGP signature
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote: On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote: Anyway, I really want a slightly different approach than what Jon is doing, that is a 3 modules scenario: - A basic stub module that attaches to the PCI card. It doesn't touch the hardware per-se (thus won't break your VGA console, though radeonfb without fb console shouldn't either, the problem you have is a bug). That stub contains the common code like IRQ handling, card type detection, maybe vram detection etc... And some locking facility See this is what I was thinking, was that there was an fb layer below radeonfb/atyfb/whatever, or alternately that there was a generic pci handler for each device. Apparently radeonfb is the lowest level right now. Why don't we start with a two module system which is already 90% written. There is nothing stopping it from being split into a three module system later. I'm not against the three module system I just don't want to create more work to do. There are three cases: #1: fbdev only = base + fbdev #2: drm only = base + drm #3: both = base + fbdev + drm The only user of case #2 is the current X server on X86. The next gen Xegl server needs case #3. Embedded wants #1. My issue is with doing a bunch of work to support case #2 since #2 will be eliminated by the new Xegl server. If case #2 is eliminated the need for the three module system is eliminated too. #1: fbdev only = base + fbdev #3: both = base + fbdev + drm base and fbdev are alway used together, what is the point in splitting them? Case #2 only involves desktop class systems, not embedded ones. Why do a bunch of work to get back 50K of RAM on a desktop system with 500MB of RAM when the case is going to be phased out. If Xegl fails we can always go back and split fbdev to make the third module and recover the ram. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday, June 10, 2005 4:38 pm, Benjamin Herrenschmidt wrote: Anyway, I really want a slightly different approach than what Jon is doing, that is a 3 modules scenario: - A basic stub module that attaches to the PCI card. It doesn't touch the hardware per-se (thus won't break your VGA console, though radeonfb without fb console shouldn't either, the problem you have is a bug). That stub contains the common code like IRQ handling, card type detection, maybe vram detection etc... And some locking facility - Depending on the above, an optional fbdev module that provides the fbdev interface mode setting - Depending on the first one too, but independant from the fbdev one, the DRM module providing the radeon DRM kernel interface What's the advantage of this if the fb part of the driver is typically needed? (I'm assuming it'll be used for modesetting at the very least in Linux.) Is it just to avoid issues with the VGA driver? Maybe it's the right way to go in the long run, but I see no problem with Jon's approach as an intermediate (if not final) step. Jesse --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Fri, 2005-06-10 at 20:03 -0400, Adam Jackson wrote: On Friday 10 June 2005 19:38, Benjamin Herrenschmidt wrote: Anyway, I really want a slightly different approach than what Jon is doing, that is a 3 modules scenario: - A basic stub module that attaches to the PCI card. It doesn't touch the hardware per-se (thus won't break your VGA console, though radeonfb without fb console shouldn't either, the problem you have is a bug). That stub contains the common code like IRQ handling, card type detection, maybe vram detection etc... And some locking facility See this is what I was thinking, was that there was an fb layer below radeonfb/atyfb/whatever, or alternately that there was a generic pci handler for each device. Apparently radeonfb is the lowest level right now. Yes. There can't be a generic PCI handler for lots of reasons, you can't just have several independent drivers tap the same HW without proper locking, arbitration other device specific things. But we can make a radeon-specific stub that puts that common code in a single place and lets the other bits optionally get on top. However, Jon approach is fine for now, as long as the bug that cause the VGA console to be wiped out is fixed. I sent Andrew a patch for it today. Ben. --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Merging radeon DRM and fbdev on Linux
On Friday 10 June 2005 20:13, Jon Smirl wrote: Why don't we start with a two module system which is already 90% written. There is nothing stopping it from being split into a three module system later. I'm not against the three module system I just don't want to create more work to do. Because technically this patch is bogus if it ever gets merged back to DRM CVS. It will break BSD, video/radeon_share.h is a linuxism, and you've added that and calls to your new radeonfb stublets in shared-core. Moving the chip flags out of drm_pciids.h is a waste of time, they're just going to get regenerated from the text file. And apparently the reason you did that is to replace (dev_priv-flags CHIP_HAS_HIERZ) with radeonfb_has_heirz(dev_priv-fb_handle). I don't see the win in pushing that info down to the radeonfb layer, since it apparently isn't needed there. Oh, and you broke HyperZ, because afaict you never initialize -family to anything. Worse than that, struct radeonfb_info doesn't even have a -family member. So this won't even _build_, let alone work. My issue is with doing a bunch of work to support case #2 since #2 will be eliminated by the new Xegl server. You keep saying that as though it were going to be true. And if you'd stop saying it the perceived hostility - on both sides - would probably go down quite a bit. We're all quite aware of what your goals are, we really don't need to be told them every five minutes. - ajax pgpuURGKsndTQ.pgp Description: PGP signature
Re: Merging radeon DRM and fbdev on Linux
On 6/10/05, Adam Jackson [EMAIL PROTECTED] wrote: Because technically this patch is bogus if it ever gets merged back to DRM CVS. It will break BSD, video/radeon_share.h is a linuxism, and you've added that and calls to your new radeonfb stublets in shared-core. BSD would have it's own equivalent of the inlines for getting the flags. BSD is already getting the flags with a different scheme than Linux. There will probably be other places where BSD needs special code, for example attaching to the interrupt vector. radeon_share means shared between fbdev/DRM not with BSD. I also did not present this patch as being ready for BSD support, it is generated against the Linux kernel tree not DRM CVS. Moving the chip flags out of drm_pciids.h is a waste of time, they're just going to get regenerated from the text file. And apparently the reason you did that is to replace (dev_priv-flags CHIP_HAS_HIERZ) with radeonfb_has_heirz(dev_priv-fb_handle). I don't see the win in pushing that info down to the radeonfb layer, since it apparently isn't needed there. I did it so that maintenance of the flags would be in a single place. All of those flags are exactly duplicated in radeonfb. If I recall right I'm the one who added the flag code to DRM to begin with and I copied it out of radeonfb. The flags were a quick way to demonstrate that radeon drm/fb could share data and routines. Oh, and you broke HyperZ, because afaict you never initialize -family to anything. Worse than that, struct radeonfb_info doesn't even have a -family member. So this won't even _build_, let alone work. Not sure where you are looking, but according to bk revtool struct radeonfb_info has had a family field since radeonfb.h was created on 2/12/04. There are two radeonfb drivers in the Linux tree. There is an old one that should be removed in drivers/video. The real one is in drivers/video/aty. The patch was generated against the one in drivers/video/aty. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
