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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
30 matches
Mail list logo