[Bug 24041] [KMS] KMS fails to initalize, in a rs690

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=24041

--- Comment #3 from Jerome Glisse  2010-04-13 02:42:41 
PDT ---
So only 2.6.31 is affected ? Does it works with recent kernel (2.6.33 or
2.6.34) ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.

2010-04-13 Thread Luc Verhaegen 
On Sat, Apr 10, 2010 at 04:44:09PM +0100, Keith Whitwell wrote:
> I haven't been following this very closely, so apologies if I'm going
> over established ground.
> 
> This patch appears to create new libraries from some subset of Mesa's
> internals.  At a guess you're selecting some internal interface(s)
> within mesa to become the public API of those libraries?  I'm pretty
> sure that's not something we're trying to achieve in this project.

Why is this not something that you're trying to achieve in this project?

It seems like simply good software development practice.

> We have public APIs which we respect and implement, and which are
> maintained and evolved under the Khronos umbrella.
> 
> We have a strong driver-level interface (ie gallium) which we benefit
> greatly from being rev as fast and as hard as we can, to adapt to our
> evolving understanding of the problem space.  We really don't want to
> subject that interface to the strictures that come with becoming a
> public API or ABI.

So you just do not want to provide the free software world with the 
ability to just update drivers, and instead want everyone to keep 
updating most of their installations when they encounter a bug?

There is a need to have integrated driver stacks from all sides. The 
only involved party that is against this is some of the developers. 
Hardware vendors, distribution vendors, and all factions of users that 
you can name, they all have an explicit need on being able to update 
drivers without having to update the rest of their often extensively 
tested and trusted software.

This is not a desire, like wanting windows/console like performance, and 
a really bling desktop. It is a tangible and clearly identifiable need.

Without this ability to update graphics driver stacks without having to 
update the whole of the installation, we can rest assured that the free 
software desktop will never happen.

You claim that you have a strong interface with gallium, but in the 
same sentence, you claim that you have a need to completely change that 
interface all the time. These two things don't really go together.

By exporting this interface, you do not kill the ability to throw the 
interface around completely. You just cannot do so gratuitously anymore; 
you have to do some versioning and you have to updating what, in the 
end, will be external drivers. This is just more hassle over the current 
mode of working, and not exactly an unovercomable hurdle.

The reward for that will be that driver developers can get their users 
to test updated drivers quickly and easily (as long as those updates do 
not depend on infrastructure changes), which vastly increases the 
likelyhood that these users get a good experience with their linux 
desktop in the near future.

But having said that, going from one end of the scale to the completely 
opposite is impossible, and my patches are taking the first careful 
steps, showing the way forward, and are not forcing anything on the mesa 
developers.

> We have a third interface, the Mesa driver interface, which may appear
> relatively stable, but which is more accurately described as
> neglected, veering towards deprecated.  The shortcomings of this
> interface, in particular its porous nature and inappropriate
> abstraction level, were major catalysts provoking the development of
> gallium.  Those shortcomings would also make it less than appropriate
> as a public API.  At some point in the future, that interface will
> either roar back into rapid evolution or truly be deprecated in favour
> of either gallium or a low-level, legacy-free GL3/4 subset from
> Khronos.
> 
> I can't easily tell from your patch what interfaces these new
> libraries have, or what expectations there would be for maintaining
> compatibility on those interfaces going forward.  I'd like to see that
> spelled out explicitly.  Without investigating further, I can say I'm
> not aware of any interface within Mesa which we'd be happy to promote
> to a public interface, nor one which we'd be happy to accept extra
> restrictions on in terms of compatibility.

The fact that the driver interface for mesa/dri is a mess, only aids my 
point here. If this SDK had been created earlier (as in, way before 
mesa 7.5, when gallium was pulled into master), then the mesa/dri 
interface would be much less of a mess today.

The fact that you consider the mesa/dri mostly dead to me just means 
that this SDK is going to be rather stable and will not require much in 
the way of maintenance anymore after this.

With the drivers and the SDKs i have created in my personaly git repos, 
I have gone all the way back to 7.0.3. I lost count on how many 
different versions there are with SDK, but i think somewhere between 15 
and 20 currently. The changes to the SDK are all pretty managable, 
and i more often have had to spend time adjusting for build system 
changes and mesa internal dependencies than anything else. This quite 
effectively proves the

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #22 from Michael Lothian  2010-04-13 05:56:11 
PDT ---
(In reply to comment #21)
> Can you try 2.6.34-rc4, please?

I can confirm this works brilliantly

Kudos in getting it into the 2.6.34 release

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

Rafał Miłecki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #23 from Rafał Miłecki  2010-04-13 06:37:30 PDT 
---
(In reply to comment #22)
> (In reply to comment #21)
> > Can you try 2.6.34-rc4, please?
> 
> I can confirm this works brilliantly
> 
> Kudos in getting it into the 2.6.34 release

That's great to hear that! Closing bug then :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: disable the tv encoder when tv/cv is not in use

2010-04-13 Thread Alex Deucher 
>From 655a7b3c698892ae38dda2d5b150e82f1e35e818 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Tue, 13 Apr 2010 11:21:59 -0400
Subject: [PATCH] drm/radeon/kms: disable the tv encoder when tv/cv is not in use

Switching between TV and VGA caused VGA to break on some systems
since the TV encoder was left enabled when VGA was used.

fixes fdo bug 25520.

Signed-off-by: Alex Deucher 
Cc: stable 
---
 drivers/gpu/drm/radeon/radeon_encoders.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index c52fc30..d61a141 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1373,8 +1373,12 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
case ENCODER_OBJECT_ID_INTERNAL_DAC2:
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
atombios_dac_setup(encoder, ATOM_ENABLE);
-   if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT |
ATOM_DEVICE_CV_SUPPORT))
-   atombios_tv_setup(encoder, ATOM_ENABLE);
+   if (radeon_encoder->devices & (ATOM_DEVICE_TV_SUPPORT |
ATOM_DEVICE_CV_SUPPORT)) {
+   if (radeon_encoder->active_device & 
(ATOM_DEVICE_TV_SUPPORT |
ATOM_DEVICE_CV_SUPPORT))
+   atombios_tv_setup(encoder, ATOM_ENABLE);
+   else
+   atombios_tv_setup(encoder, ATOM_DISABLE);
+   }
break;
}
atombios_apply_encoder_quirks(encoder, adjusted_mode);
-- 
1.5.6.3
From 655a7b3c698892ae38dda2d5b150e82f1e35e818 Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Tue, 13 Apr 2010 11:21:59 -0400
Subject: [PATCH] drm/radeon/kms: disable the tv encoder when tv/cv is not in use

Switching between TV and VGA caused VGA to break on some systems
since the TV encoder was left enabled when VGA was used.

fixes fdo bug 25520.

Signed-off-by: Alex Deucher 
Cc: stable 
---
 drivers/gpu/drm/radeon/radeon_encoders.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index c52fc30..d61a141 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1373,8 +1373,12 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
 	case ENCODER_OBJECT_ID_INTERNAL_DAC2:
 	case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
 		atombios_dac_setup(encoder, ATOM_ENABLE);
-		if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT | ATOM_DEVICE_CV_SUPPORT))
-			atombios_tv_setup(encoder, ATOM_ENABLE);
+		if (radeon_encoder->devices & (ATOM_DEVICE_TV_SUPPORT | ATOM_DEVICE_CV_SUPPORT)) {
+			if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT | ATOM_DEVICE_CV_SUPPORT))
+atombios_tv_setup(encoder, ATOM_ENABLE);
+			else
+atombios_tv_setup(encoder, ATOM_DISABLE);
+		}
 		break;
 	}
 	atombios_apply_encoder_quirks(encoder, adjusted_mode);
-- 
1.5.6.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #24 from Andy Green  2010-04-13 12:21:23 PDT ---
I can also confirm it's solved (and compiz!) well done.

However now I get overscan on the HDMI where I had 1:1 pixels before.

I guess it's a different bug if you don't have any hint.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff

2010-04-13 Thread Marcin Slusarz 
On Mon, Apr 12, 2010 at 11:33:27PM +0200, Marcin Slusarz wrote:
> > > > Have you got a pointer to a machine where it fails?
> > > 
> > > No, it failed with an artifical test while I was working on vga16fb 
> > > handoff
> > > (unfinished).
> > 
> > You won't be able to make this work for vga16fb from what I can see
> > since it access 0xa000 directly, not via any of the defined apertures
> > that vesafb/offb use. vga16fb will need a different approach I suspect.
> 
> Yeah, there's an idea to claim 0xa as an aperture of vga16fb and then
> do the same in KMS driver but only if it's the primary card. 
> (You hinted to use SHADOW resource bit to check whether card is primary)
> I think I'll try this approach soon.

Patch below works for me, but I couldn't test the case when nvidia card is 
secondary.

---
From: Marcin Slusarz 
Date: Tue, 13 Apr 2010 09:20:53 +0200
Subject: [PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff

let vga16fb claim 0xA+0x1 region as its aperture;
nouveau does not use it, so we need to lie to kick vga16fb,
but only if it's driving the primary card (by checking
IORESOURCE_ROM_SHADOW resource flag)

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nouveau_state.c |   11 ++-
 drivers/video/vga16fb.c |   26 +++---
 2 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index cfa3239..a101861 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -636,10 +636,12 @@ static void nouveau_OF_copy_vbios_to_ramin(struct 
drm_device *dev)
 #endif
 }
 
+#define VGA_FB_PHYS 0xA
+#define VGA_FB_PHYS_LEN 65536
 static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev)
 {
struct pci_dev *pdev = dev->pdev;
-   struct apertures_struct *aper = alloc_apertures(3);
+   struct apertures_struct *aper = alloc_apertures(4);
if (!aper)
return NULL;
 
@@ -658,6 +660,13 @@ static struct apertures_struct 
*nouveau_get_apertures(struct drm_device *dev)
aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
aper->count++;
}
+   
+   /* if it's the primary card, claim 0xa as ours to kick vga16fb */
+   if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW) {
+   aper->ranges[aper->count].base = VGA_FB_PHYS;
+   aper->ranges[aper->count].size = VGA_FB_PHYS_LEN;
+   aper->count++;
+   }
 
return aper;
 }
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 76d8dae..45d7a3d 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1264,10 +1264,19 @@ static void vga16fb_imageblit(struct fb_info *info, 
const struct fb_image *image
vga_imageblit_color(info, image);
 }
 
+static void vga16fb_destroy(struct fb_info *info)
+{
+   iounmap(info->screen_base);
+   fb_dealloc_cmap(&info->cmap);
+   /* XXX unshare VGA regions */
+   framebuffer_release(info);
+}
+
 static struct fb_ops vga16fb_ops = {
.owner  = THIS_MODULE,
.fb_open= vga16fb_open,
.fb_release = vga16fb_release,
+   .fb_destroy = vga16fb_destroy,
.fb_check_var   = vga16fb_check_var,
.fb_set_par = vga16fb_set_par,
.fb_setcolreg   = vga16fb_setcolreg,
@@ -1307,6 +1316,11 @@ static int __devinit vga16fb_probe(struct 
platform_device *dev)
ret = -ENOMEM;
goto err_fb_alloc;
}
+   info->apertures = alloc_apertures(1);
+   if (!info->apertures) {
+   ret = -ENOMEM;
+   goto err_ioremap;
+   }
 
/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
@@ -1336,7 +1350,7 @@ static int __devinit vga16fb_probe(struct platform_device 
*dev)
info->fix = vga16fb_fix;
/* supports rectangles with widths of multiples of 8 */
info->pixmap.blit_x = 1 << 7 | 1 << 15 | 1 << 23 | 1 << 31;
-   info->flags = FBINFO_FLAG_DEFAULT |
+   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
FBINFO_HWACCEL_YPAN;
 
i = (info->var.bits_per_pixel == 8) ? 256 : 16;
@@ -1355,6 +1369,9 @@ static int __devinit vga16fb_probe(struct platform_device 
*dev)
 
vga16fb_update_fix(info);
 
+   info->apertures->ranges[0].base = VGA_FB_PHYS;
+   info->apertures->ranges[0].size = VGA_FB_PHYS_LEN;
+
if (register_framebuffer(info) < 0) {
printk(KERN_ERR "vga16fb: unable to register framebuffer\n");
ret = -EINVAL;
@@ -1381,13 +1398,8 @@ static int vga16fb_remove(struct platform_device *dev)
 {
struct fb_info *info = platform_get_drvdata(dev);
 
-   if (info) {
+   if (info)
u

[Bug 27402] [r300g] Earth textures in celestia are partially corrupted in all rendering paths

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=27402

--- Comment #10 from Chris Rankin  2010-04-13 12:59:00 
PDT ---
Earth textures are now completely missing in all rendering paths. Earth has
become Hoth.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #25 from Alex Deucher  2010-04-13 12:59:08 PDT ---
(In reply to comment #24)
> However now I get overscan on the HDMI where I had 1:1 pixels before.

Did you change any settings on your TV?  Some TV's overscan by default unless
you disable it in the TV options.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #26 from Andy Green  2010-04-13 13:56:48 PDT ---
Created an attachment (id=34978)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=34978)
Xorg log with overscanned HDMI out (no green cast!) on Aspire 8935

> Did you change any settings on your TV? 

No it's the same TV I used for some months; immediately before the kernel
upgrade it was showing 1:1 pixel 1920 x 1080 and after it's overscanned.

There's no setting for overscan in the TV's menu system either with HDMI input
source.

I attach the current /var/log/Xorg.0.log showing overscan, I previously
attached one that shows 1:1 pixels on the same laptop and TV.

I guess it can make sense to open a new bug, just wondering if there's a magic
Option somewhere to guide it not to overscan.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #27 from Alex Deucher  2010-04-13 14:04:37 PDT ---
(In reply to comment #26)
> No it's the same TV I used for some months; immediately before the kernel
> upgrade it was showing 1:1 pixel 1920 x 1080 and after it's overscanned.
> 
> There's no setting for overscan in the TV's menu system either with HDMI input
> source.
> 
> I attach the current /var/log/Xorg.0.log showing overscan, I previously
> attached one that shows 1:1 pixels on the same laptop and TV.
> 
> I guess it can make sense to open a new bug, just wondering if there's a magic
> Option somewhere to guide it not to overscan.

Yes, file a new bug.  Are you using hdmi audio or just video?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_handle_t type

2010-04-13 Thread Matthew W. S. Bell 
On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
> On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
> > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
> > > Its probably not documented well anywhere, though I think the handles are
> > > 32-bit is written down somewhere.
> > 
> > Ah sorry, I missed some.
> 
> drm_handle_t is correct here... 

No, drm_handle_t can be of a different size to void *; converting
between integers and pointers of different sizes causes a warning. To
eliminate the warning, the value first needs to be passed between
uintptr_t and void *, which are of the same size, and then converted to
drm_handle_t. The last part is implicit; the drm_handle_t casts are
irrelevant/useless.

Matthew


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa3d-dev] Move lists to freedesktop.org?

2010-04-13 Thread Matthew W. S. Bell 
On Thu, 2010-04-08 at 16:37 -0700, Jesse Barnes wrote:
> On Thu, 8 Apr 2010 18:38:03 -0400
> Alex Deucher  wrote:
> 
> > On Thu, Apr 8, 2010 at 6:21 PM, Brian Paul  wrote:
> > >
> > > Unless there's some objection I'm going to subscribe everyone to the
> > > new FD.O-based mesa-dev mailing list who's on the mesa3d-dev list.
> > > Probably in the next 24 hours.
> > >
> > > Then, some of you may have to log into the mailman interface
> > > (http://lists.freedesktop.org/mailman/listinfo/mesa-dev) to set digest
> > > mode, etc.
> > >
> > > -Brian
> > 
> > Are there plans to move dri-devel as well?
> 
> Yeah, I'm just getting the info for that now.  But I don't think we
> have subscriber lists, so everyone will have to re-subscribe to the new
> list.
> 
> I'll send out a note to dri-devel when it's all set.

Would you update ? I tried
to do it myself, but I don't appear to be human enough to pass the
textcha and register an account.

Matthew W.S. Bell


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/2] drm/radeon/kms: tex3D mipmap fix & R500 VAP regs

2010-04-13 Thread Marek Olšák 
On Sun, Apr 11, 2010 at 8:12 PM, Jerome Glisse wrote:

> On Sun, Apr 11, 2010 at 06:39:05AM +0200, Marek Olšák wrote:
> > Hi devs,
> >
> > The first attached patch fixes the calculation of mipmapped 3D texture
> sizes
> > in the CS checker, the 3rd dimension (depth) should be minified too. This
> > should probably go to 2.6.34.
> >
> > The second patch adds 2 new regs:
> > - VAP_ALT_NUM_VERTICES, along with an update to the CS checker.
> > - VAP_INDEX_OFFSET, I don't think this one needs to be tracked, because
> we
> > have min/max vertex index clamping, but I might be wrong.
> >
>
> I need to recheck but iirc VAP_INDEX_OFFSET doesn't count in the
> min max clipping ie we need to track it.


GL places index clamping prior to adding the index offset and if hw follows
this rule, there is nothing sane to be done. VAP_INDEX_OFFSET is completely
orthogonal to VAP_VF_MAX_VTX_INDX. The latter contains a minimum allowed
buffer-object size divided by a stride, having nothing to do with actual
indices. To support index offsets, we would have to check content of every
index buffer, which I am not a fan of. Opinions?

-Marek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_handle_t type

2010-04-13 Thread Robert Noland 
On Wed, 2010-04-14 at 00:19 +0100, Matthew W. S. Bell wrote:
> On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
> > On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
> > > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
> > > > Its probably not documented well anywhere, though I think the handles 
> > > > are
> > > > 32-bit is written down somewhere.
> > > 
> > > Ah sorry, I missed some.
> > 
> > drm_handle_t is correct here... 
> 
> No, drm_handle_t can be of a different size to void *; converting
> between integers and pointers of different sizes causes a warning. To
> eliminate the warning, the value first needs to be passed between
> uintptr_t and void *, which are of the same size, and then converted to
> drm_handle_t. The last part is implicit; the drm_handle_t casts are
> irrelevant/useless.

My point being that the casts to drm_handle_t are correct.  Feel free to
fix linux' define for drm_handle_t.

robert. 

> Matthew
-- 
Robert Noland 
2Hip Networks

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_handle_t type

2010-04-13 Thread Dave Airlie 
On Wed, Apr 14, 2010 at 1:32 PM, Robert Noland  wrote:
> On Wed, 2010-04-14 at 00:19 +0100, Matthew W. S. Bell wrote:
>> On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
>> > On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
>> > > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
>> > > > Its probably not documented well anywhere, though I think the handles 
>> > > > are
>> > > > 32-bit is written down somewhere.
>> > >
>> > > Ah sorry, I missed some.
>> >
>> > drm_handle_t is correct here...
>>
>> No, drm_handle_t can be of a different size to void *; converting
>> between integers and pointers of different sizes causes a warning. To
>> eliminate the warning, the value first needs to be passed between
>> uintptr_t and void *, which are of the same size, and then converted to
>> drm_handle_t. The last part is implicit; the drm_handle_t casts are
>> irrelevant/useless.
>
> My point being that the casts to drm_handle_t are correct.  Feel free to
> fix linux' define for drm_handle_t.
>

Weird the drm is defined on Linux and is considered the standard, and
uint32_t is considered correct handle sizing on Linux.

I'm not sure why FreeBSD didn't change to 32-bit handles at the same
time, I think nobody wanted to break stuff by accident at the time,
assuming FreeBSD maintainers would take care of it.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm_handle_t type

2010-04-13 Thread Robert Noland 
On Wed, 2010-04-14 at 00:19 +0100, Matthew W. S. Bell wrote:
> On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
> > On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
> > > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
> > > > Its probably not documented well anywhere, though I think the handles 
> > > > are
> > > > 32-bit is written down somewhere.
> > > 
> > > Ah sorry, I missed some.
> > 
> > drm_handle_t is correct here... 
> 
> No, drm_handle_t can be of a different size to void *; converting
> between integers and pointers of different sizes causes a warning. To
> eliminate the warning, the value first needs to be passed between
> uintptr_t and void *, which are of the same size, and then converted to
> drm_handle_t. The last part is implicit; the drm_handle_t casts are
> irrelevant/useless.

No, if you look at the BSD define for drm_handle_t, it does the right
thing on each arch.  The problem is that the linux define for
drm_handle_t is u32.

robert.

> Matthew
-- 
Robert Noland 
2Hip Networks

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] fbmem: fix aperture overlapping check

2010-04-13 Thread Dave Airlie 
On Mon, 2010-04-12 at 13:34 +0200, Marcin Slusarz wrote:
> On Mon, Apr 12, 2010 at 09:54:28AM +1000, Dave Airlie wrote:
> > On Sat, 2010-04-10 at 21:55 +0200, marcin.slusarz at gmail.com wrote:
> > > fb_do_apertures_overlap is returning wrong value when one aperture
> > > is completely whithin the other. Add generic ranges_overlap macro
> > > (probably kernel.h candidate) and use it here.
> > > 
> > 
> > That doesn't seem right.
> > 
> > The rules are:
> > 
> > the generic aperture has to be equal or smaller than the hw aperture,
> > otherwise the generic driver will be trashing random hw pieces on the
> > machine.

> Why "it has to"? Why generic aperture can't start one byte before hw?

Think about how it works a bit more, the answer is obvious.

The hw aperture is defined by the actual hardware, not by the OS or my
code. The PCI apertures are well defined. Now for a generic driver like
vesa or offb to access the hardware it needs to access the hw apertures.

It can't go accessing one byte before the hw aperture, as that will
crash the machine, or write to some other devices hw.

> 
> > So with that in mind, the check makes sure the generic aperture starts
> > somewhere inside the hw aperture, which the test clearly gets right.
> 
> So your only objection is that it's impossible with the current code?
> 
> > Have you got a pointer to a machine where it fails?
> 
> No, it failed with an artifical test while I was working on vga16fb handoff
> (unfinished).

You won't be able to make this work for vga16fb from what I can see
since it access 0xa000 directly, not via any of the defined apertures
that vesafb/offb use. vga16fb will need a different approach I suspect.

Dave.

[PATCHv2 2/2] fbmem, drm/nouveau: kick firmware framebuffers as soon as possible

2010-04-13 Thread marcin.slus...@gmail.com 
Currently vesafb/efifb/... is kicked when hardware driver is registering
framebuffer. To do it hardware must be fully functional, so there's a short
window between start of initialisation and framebuffer registration when
two drivers touch the hardware. Unfortunately sometimes it breaks nouveau
initialisation.

Fix it by kicking firmware driver(s) before we start touching the hardware.

Reported-by: Didier Spaier 
Tested-by: Didier Spaier 
Signed-off-by: Marcin Slusarz 
Cc: Ben Skeggs 
Cc: Dave Airlie 
Cc: Peter Jones 
Cc: Andrew Morton 
---
v2 - rebase after drop of patch 1/3 + compile fix
---
 drivers/gpu/drm/nouveau/nouveau_drv.h   |2 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   19 +-
 drivers/gpu/drm/nouveau/nouveau_state.c |   43 +++
 drivers/video/fbmem.c   |   43 ++-
 include/linux/fb.h  |1 +
 5 files changed, 72 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index cb16a1b..a1f61f7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -621,6 +621,8 @@ struct drm_nouveau_private {
struct {
struct dentry *channel_root;
} debugfs;
+
+   struct apertures_struct *apertures;
 };

 static inline struct drm_nouveau_private *
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 206368b..5e4367b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -195,7 +195,6 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t 
fb_width,
struct drm_mode_fb_cmd mode_cmd;
struct pci_dev *pdev = dev->pdev;
struct device *device = &pdev->dev;
-   struct apertures_struct *aper;
int size, ret;

mode_cmd.width = surface_width;
@@ -282,28 +281,12 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t 
fb_width,
info->fix.mmio_len = pci_resource_len(pdev, 1);

/* Set aperture base/size for vesafb takeover */
-   aper = info->apertures = alloc_apertures(3);
+   info->apertures = dev_priv->apertures;
if (!info->apertures) {
ret = -ENOMEM;
goto out_unref;
}

-   aper->ranges[0].base = pci_resource_start(pdev, 1);
-   aper->ranges[0].size = pci_resource_len(pdev, 1);
-   aper->count = 1;
-
-   if (pci_resource_len(pdev, 2)) {
-   aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
-   aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
-   aper->count++;
-   }
-
-   if (pci_resource_len(pdev, 3)) {
-   aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
-   aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
-   aper->count++;
-   }
-
info->pixmap.size = 64*1024;
info->pixmap.buf_align = 8;
info->pixmap.access_align = 32;
diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index a9e9cf3..cfa3239 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -636,6 +636,43 @@ static void nouveau_OF_copy_vbios_to_ramin(struct 
drm_device *dev)
 #endif
 }

+static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev)
+{
+   struct pci_dev *pdev = dev->pdev;
+   struct apertures_struct *aper = alloc_apertures(3);
+   if (!aper)
+   return NULL;
+
+   aper->ranges[0].base = pci_resource_start(pdev, 1);
+   aper->ranges[0].size = pci_resource_len(pdev, 1);
+   aper->count = 1;
+
+   if (pci_resource_len(pdev, 2)) {
+   aper->ranges[aper->count].base = pci_resource_start(pdev, 2);
+   aper->ranges[aper->count].size = pci_resource_len(pdev, 2);
+   aper->count++;
+   }
+
+   if (pci_resource_len(pdev, 3)) {
+   aper->ranges[aper->count].base = pci_resource_start(pdev, 3);
+   aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
+   aper->count++;
+   }
+
+   return aper;
+}
+
+static int nouveau_remove_conflicting_drivers(struct drm_device *dev)
+{
+   struct drm_nouveau_private *dev_priv = dev->dev_private;
+   dev_priv->apertures = nouveau_get_apertures(dev);
+   if (!dev_priv->apertures)
+   return -ENOMEM;
+   
+   remove_conflicting_framebuffers(dev_priv->apertures, "nouveaufb");
+   return 0;
+}
+
 int nouveau_load(struct drm_device *dev, unsigned long flags)
 {
struct drm_nouveau_private *dev_priv;
@@ -723,6 +760,12 @@ int nouveau_load(struct drm_device *dev, unsigned long 
flags)
NV_INFO(dev, "Detected an NV%2x generation card (0x%08x)\n",
dev_priv->card_type, reg0);

+   if (drm_core_check_featu

[PATCHv2 1/2] fbdev: allow passing more than one aperture for handoff

2010-04-13 Thread marcin.slus...@gmail.com 
It simplifies nouveau code by removal of detection which
region to pass to kick vesafb/efifb.

Signed-off-by: Marcin Slusarz 
Cc: Eric Anholt 
Cc: Ben Skeggs 
Cc: Thomas Hellstrom 
Cc: Dave Airlie 
Cc: Peter Jones 
Cc: Andrew Morton 
Cc: Benjamin Herrenschmidt 
---
v2 - rebase after drop of patch 1/3
---
 drivers/gpu/drm/i915/intel_fb.c |   11 +++-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |   84 +-
 drivers/gpu/drm/radeon/radeon_fb.c  |9 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |   10 +++-
 drivers/video/efifb.c   |   11 +++-
 drivers/video/fbmem.c   |   29 ++-
 drivers/video/fbsysfs.c |1 +
 drivers/video/offb.c|   28 ++
 drivers/video/vesafb.c  |   11 +++-
 include/linux/fb.h  |   16 +-
 10 files changed, 122 insertions(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 8cd791d..a9192ab 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -192,11 +192,16 @@ static int intelfb_create(struct drm_device *dev, 
uint32_t fb_width,


/* setup aperture base/size for vesafb takeover */
-   info->aperture_base = dev->mode_config.fb_base;
+   info->apertures = alloc_apertures(1);
+   if (!info->apertures) {
+   ret = -ENOMEM;
+   goto out_unpin;
+   }
+   info->apertures->ranges[0].base = dev->mode_config.fb_base;
if (IS_I9XX(dev))
-   info->aperture_size = pci_resource_len(dev->pdev, 2);
+   info->apertures->ranges[0].size = pci_resource_len(dev->pdev, 
2);
else
-   info->aperture_size = pci_resource_len(dev->pdev, 0);
+   info->apertures->ranges[0].size = pci_resource_len(dev->pdev, 
0);

info->fix.smem_start = dev->mode_config.fb_base + obj_priv->gtt_offset;
info->fix.smem_len = size;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 68cedd9..206368b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -161,44 +161,6 @@ static struct drm_fb_helper_funcs 
nouveau_fbcon_helper_funcs = {
.gamma_get = nouveau_fbcon_gamma_get
 };

-#if defined(__i386__) || defined(__x86_64__)
-static bool
-nouveau_fbcon_has_vesafb_or_efifb(struct drm_device *dev)
-{
-   struct pci_dev *pdev = dev->pdev;
-   int ramin;
-
-   if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB &&
-   screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
-   return false;
-
-   if (screen_info.lfb_base < pci_resource_start(pdev, 1))
-   goto not_fb;
-
-   if (screen_info.lfb_base + screen_info.lfb_size >=
-   pci_resource_start(pdev, 1) + pci_resource_len(pdev, 1))
-   goto not_fb;
-
-   return true;
-not_fb:
-   ramin = 2;
-   if (pci_resource_len(pdev, ramin) == 0) {
-   ramin = 3;
-   if (pci_resource_len(pdev, ramin) == 0)
-   return false;
-   }
-
-   if (screen_info.lfb_base < pci_resource_start(pdev, ramin))
-   return false;
-
-   if (screen_info.lfb_base + screen_info.lfb_size >=
-   pci_resource_start(pdev, ramin) + pci_resource_len(pdev, ramin))
-   return false;
-
-   return true;
-}
-#endif
-
 void
 nouveau_fbcon_zfill(struct drm_device *dev)
 {
@@ -231,7 +193,9 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t 
fb_width,
struct nouveau_framebuffer *nouveau_fb;
struct nouveau_bo *nvbo;
struct drm_mode_fb_cmd mode_cmd;
-   struct device *device = &dev->pdev->dev;
+   struct pci_dev *pdev = dev->pdev;
+   struct device *device = &pdev->dev;
+   struct apertures_struct *aper;
int size, ret;

mode_cmd.width = surface_width;
@@ -314,28 +278,30 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t 
fb_width,
drm_fb_helper_fill_var(info, fb, fb_width, fb_height);

/* FIXME: we really shouldn't expose mmio space at all */
-   info->fix.mmio_start = pci_resource_start(dev->pdev, 1);
-   info->fix.mmio_len = pci_resource_len(dev->pdev, 1);
+   info->fix.mmio_start = pci_resource_start(pdev, 1);
+   info->fix.mmio_len = pci_resource_len(pdev, 1);

/* Set aperture base/size for vesafb takeover */
-#if defined(__i386__) || defined(__x86_64__)
-   if (nouveau_fbcon_has_vesafb_or_efifb(dev)) {
-   /* Some NVIDIA VBIOS' are stupid and decide to put the
-* framebuffer in the middle of the PRAMIN BAR for
-* whatever reason.  We need to know the exact lfb_base
-* to get vesafb kicked off, and the only reliable way
-* we have left is to find out lfb_base the same way
-* vesafb did.
-

[PATCH 1/3] fbmem: fix aperture overlapping check

2010-04-13 Thread Dave Airlie 
>
> Ok, thanks for explanation. I'll drop this patch and rebase the others.

Cool,

>> You won't be able to make this work for vga16fb from what I can see
>> since it access 0xa000 directly, not via any of the defined apertures
>> that vesafb/offb use. vga16fb will need a different approach I suspect.
>
> Yeah, there's an idea to claim 0xa as an aperture of vga16fb and then
> do the same in KMS driver but only if it's the primary card.
> (You hinted to use SHADOW resource bit to check whether card is primary)
> I think I'll try this approach soon.

Yeah as long as we kick it off once, certain things like vga switcheroo change
who the primary gpu is at runtime.

but it should be okay if both drivers have the kickoff paths.

Dave.

[PATCH] i915: Fix comments about cube layouts

2010-04-13 Thread Jakob Bornecrantz 
---
 src/mesa/drivers/dri/i915/i915_tex_layout.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/mesa/drivers/dri/i915/i915_tex_layout.c 
b/src/mesa/drivers/dri/i915/i915_tex_layout.c
index 7026552..c98dede 100644
--- a/src/mesa/drivers/dri/i915/i915_tex_layout.c
+++ b/src/mesa/drivers/dri/i915/i915_tex_layout.c
@@ -67,7 +67,8 @@ static GLint bottom_offsets[6] = {


 /**
- * Cube texture map layout for i830M-GM915.
+ * Cube texture map layout for i830M-GM915 and
+ * none compressed cube texture map on GM945.
  *
  * Hardware layout looks like:
  *
@@ -258,7 +259,7 @@ i915_miptree_layout(struct intel_context *intel, struct 
intel_mipmap_tree * mt,


 /**
- * Cube texture map layout for GM945 and later.
+ * Compressed cube texture map layout for GM945 and later.
  *
  * The hardware layout looks like the 830-915 layout, except for the small
  * sizes.  A zoomed in view of the layout for 945 is:
-- 
1.6.0.4

[Bug 24041] [KMS] KMS fails to initalize, in a rs690

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=24041

--- Comment #3 from Jerome Glisse  2010-04-13 
02:42:41 PDT ---
So only 2.6.31 is affected ? Does it works with recent kernel (2.6.33 or
2.6.34) ?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.

2010-04-13 Thread Luc Verhaegen 
On Sat, Apr 10, 2010 at 04:44:09PM +0100, Keith Whitwell wrote:
> I haven't been following this very closely, so apologies if I'm going
> over established ground.
> 
> This patch appears to create new libraries from some subset of Mesa's
> internals.  At a guess you're selecting some internal interface(s)
> within mesa to become the public API of those libraries?  I'm pretty
> sure that's not something we're trying to achieve in this project.

Why is this not something that you're trying to achieve in this project?

It seems like simply good software development practice.

> We have public APIs which we respect and implement, and which are
> maintained and evolved under the Khronos umbrella.
> 
> We have a strong driver-level interface (ie gallium) which we benefit
> greatly from being rev as fast and as hard as we can, to adapt to our
> evolving understanding of the problem space.  We really don't want to
> subject that interface to the strictures that come with becoming a
> public API or ABI.

So you just do not want to provide the free software world with the 
ability to just update drivers, and instead want everyone to keep 
updating most of their installations when they encounter a bug?

There is a need to have integrated driver stacks from all sides. The 
only involved party that is against this is some of the developers. 
Hardware vendors, distribution vendors, and all factions of users that 
you can name, they all have an explicit need on being able to update 
drivers without having to update the rest of their often extensively 
tested and trusted software.

This is not a desire, like wanting windows/console like performance, and 
a really bling desktop. It is a tangible and clearly identifiable need.

Without this ability to update graphics driver stacks without having to 
update the whole of the installation, we can rest assured that the free 
software desktop will never happen.

You claim that you have a strong interface with gallium, but in the 
same sentence, you claim that you have a need to completely change that 
interface all the time. These two things don't really go together.

By exporting this interface, you do not kill the ability to throw the 
interface around completely. You just cannot do so gratuitously anymore; 
you have to do some versioning and you have to updating what, in the 
end, will be external drivers. This is just more hassle over the current 
mode of working, and not exactly an unovercomable hurdle.

The reward for that will be that driver developers can get their users 
to test updated drivers quickly and easily (as long as those updates do 
not depend on infrastructure changes), which vastly increases the 
likelyhood that these users get a good experience with their linux 
desktop in the near future.

But having said that, going from one end of the scale to the completely 
opposite is impossible, and my patches are taking the first careful 
steps, showing the way forward, and are not forcing anything on the mesa 
developers.

> We have a third interface, the Mesa driver interface, which may appear
> relatively stable, but which is more accurately described as
> neglected, veering towards deprecated.  The shortcomings of this
> interface, in particular its porous nature and inappropriate
> abstraction level, were major catalysts provoking the development of
> gallium.  Those shortcomings would also make it less than appropriate
> as a public API.  At some point in the future, that interface will
> either roar back into rapid evolution or truly be deprecated in favour
> of either gallium or a low-level, legacy-free GL3/4 subset from
> Khronos.
> 
> I can't easily tell from your patch what interfaces these new
> libraries have, or what expectations there would be for maintaining
> compatibility on those interfaces going forward.  I'd like to see that
> spelled out explicitly.  Without investigating further, I can say I'm
> not aware of any interface within Mesa which we'd be happy to promote
> to a public interface, nor one which we'd be happy to accept extra
> restrictions on in terms of compatibility.

The fact that the driver interface for mesa/dri is a mess, only aids my 
point here. If this SDK had been created earlier (as in, way before 
mesa 7.5, when gallium was pulled into master), then the mesa/dri 
interface would be much less of a mess today.

The fact that you consider the mesa/dri mostly dead to me just means 
that this SDK is going to be rather stable and will not require much in 
the way of maintenance anymore after this.

With the drivers and the SDKs i have created in my personaly git repos, 
I have gone all the way back to 7.0.3. I lost count on how many 
different versions there are with SDK, but i think somewhere between 15 
and 20 currently. The changes to the SDK are all pretty managable, 
and i more often have had to spend time adjusting for build system 
changes and mesa internal dependencies than anything else. This quite 
effectively proves the

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #22 from Michael Lothian  2010-04-13 
05:56:11 PDT ---
(In reply to comment #21)
> Can you try 2.6.34-rc4, please?

I can confirm this works brilliantly

Kudos in getting it into the 2.6.34 release

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

Rafa? Mi?ecki  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #23 from Rafa? Mi?ecki  2010-04-13 06:37:30 
PDT ---
(In reply to comment #22)
> (In reply to comment #21)
> > Can you try 2.6.34-rc4, please?
> 
> I can confirm this works brilliantly
> 
> Kudos in getting it into the 2.6.34 release

That's great to hear that! Closing bug then :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/kms: disable the tv encoder when tv/cv is not in use

2010-04-13 Thread Alex Deucher

[PATCH] drm/radeon/kms: disable the tv encoder when tv/cv is not in use

2010-04-13 Thread Alex Deucher 
Switching between TV and VGA caused VGA to break on some systems
since the TV encoder was left enabled when VGA was used.

fixes fdo bug 25520.

Signed-off-by: Alex Deucher 
Cc: stable 
---
 drivers/gpu/drm/radeon/radeon_encoders.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index c52fc30..d61a141 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1373,8 +1373,12 @@ radeon_atom_encoder_mode_set(struct drm_encoder *encoder,
case ENCODER_OBJECT_ID_INTERNAL_DAC2:
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DAC2:
atombios_dac_setup(encoder, ATOM_ENABLE);
-   if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT |
ATOM_DEVICE_CV_SUPPORT))
-   atombios_tv_setup(encoder, ATOM_ENABLE);
+   if (radeon_encoder->devices & (ATOM_DEVICE_TV_SUPPORT |
ATOM_DEVICE_CV_SUPPORT)) {
+   if (radeon_encoder->active_device & 
(ATOM_DEVICE_TV_SUPPORT |
ATOM_DEVICE_CV_SUPPORT))
+   atombios_tv_setup(encoder, ATOM_ENABLE);
+   else
+   atombios_tv_setup(encoder, ATOM_DISABLE);
+   }
break;
}
atombios_apply_encoder_quirks(encoder, adjusted_mode);
-- 
1.5.6.3

--000e0ce0f3c873437504841fe3f5
Content-Type: text/x-diff; charset=US-ASCII; 
name="0001-drm-radeon-kms-disable-the-tv-encoder-when-tv-cv-is.patch"
Content-Disposition: attachment; 

filename="0001-drm-radeon-kms-disable-the-tv-encoder-when-tv-cv-is.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g7yv7tqe0

RnJvbSA2NTVhN2IzYzY5ODg5MmFlMzhkZGEyZDViMTUwZTgyZjFlMzVlODE4IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGV4IERldWNoZXIgPGFsZXhkZXVjaGVyQGdtYWlsLmNvbT4K
RGF0ZTogVHVlLCAxMyBBcHIgMjAxMCAxMToyMTo1OSAtMDQwMApTdWJqZWN0OiBbUEFUQ0hdIGRy
bS9yYWRlb24va21zOiBkaXNhYmxlIHRoZSB0diBlbmNvZGVyIHdoZW4gdHYvY3YgaXMgbm90IGlu
IHVzZQoKU3dpdGNoaW5nIGJldHdlZW4gVFYgYW5kIFZHQSBjYXVzZWQgVkdBIHRvIGJyZWFrIG9u
IHNvbWUgc3lzdGVtcwpzaW5jZSB0aGUgVFYgZW5jb2RlciB3YXMgbGVmdCBlbmFibGVkIHdoZW4g
VkdBIHdhcyB1c2VkLgoKZml4ZXMgZmRvIGJ1ZyAyNTUyMC4KClNpZ25lZC1vZmYtYnk6IEFsZXgg
RGV1Y2hlciA8YWxleGRldWNoZXJAZ21haWwuY29tPgpDYzogc3RhYmxlIDxzdGFibGVAa2VybmVs
Lm9yZz4KLS0tCiBkcml2ZXJzL2dwdS9kcm0vcmFkZW9uL3JhZGVvbl9lbmNvZGVycy5jIHwgICAg
OCArKysrKystLQogMSBmaWxlcyBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25z
KC0pCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9ncHUvZHJtL3JhZGVvbi9yYWRlb25fZW5jb2RlcnMu
YyBiL2RyaXZlcnMvZ3B1L2RybS9yYWRlb24vcmFkZW9uX2VuY29kZXJzLmMKaW5kZXggYzUyZmMz
MC4uZDYxYTE0MSAxMDA2NDQKLS0tIGEvZHJpdmVycy9ncHUvZHJtL3JhZGVvbi9yYWRlb25fZW5j
b2RlcnMuYworKysgYi9kcml2ZXJzL2dwdS9kcm0vcmFkZW9uL3JhZGVvbl9lbmNvZGVycy5jCkBA
IC0xMzczLDggKzEzNzMsMTIgQEAgcmFkZW9uX2F0b21fZW5jb2Rlcl9tb2RlX3NldChzdHJ1Y3Qg
ZHJtX2VuY29kZXIgKmVuY29kZXIsCiAJY2FzZSBFTkNPREVSX09CSkVDVF9JRF9JTlRFUk5BTF9E
QUMyOgogCWNhc2UgRU5DT0RFUl9PQkpFQ1RfSURfSU5URVJOQUxfS0xEU0NQX0RBQzI6CiAJCWF0
b21iaW9zX2RhY19zZXR1cChlbmNvZGVyLCBBVE9NX0VOQUJMRSk7Ci0JCWlmIChyYWRlb25fZW5j
b2Rlci0+YWN0aXZlX2RldmljZSAmIChBVE9NX0RFVklDRV9UVl9TVVBQT1JUIHwgQVRPTV9ERVZJ
Q0VfQ1ZfU1VQUE9SVCkpCi0JCQlhdG9tYmlvc190dl9zZXR1cChlbmNvZGVyLCBBVE9NX0VOQUJM
RSk7CisJCWlmIChyYWRlb25fZW5jb2Rlci0+ZGV2aWNlcyAmIChBVE9NX0RFVklDRV9UVl9TVVBQ
T1JUIHwgQVRPTV9ERVZJQ0VfQ1ZfU1VQUE9SVCkpIHsKKwkJCWlmIChyYWRlb25fZW5jb2Rlci0+
YWN0aXZlX2RldmljZSAmIChBVE9NX0RFVklDRV9UVl9TVVBQT1JUIHwgQVRPTV9ERVZJQ0VfQ1Zf
U1VQUE9SVCkpCisJCQkJYXRvbWJpb3NfdHZfc2V0dXAoZW5jb2RlciwgQVRPTV9FTkFCTEUpOwor
CQkJZWxzZQorCQkJCWF0b21iaW9zX3R2X3NldHVwKGVuY29kZXIsIEFUT01fRElTQUJMRSk7CisJ
CX0KIAkJYnJlYWs7CiAJfQogCWF0b21iaW9zX2FwcGx5X2VuY29kZXJfcXVpcmtzKGVuY29kZXIs
IGFkanVzdGVkX21vZGUpOwotLSAKMS41LjYuMwoK
--000e0ce0f3c873437504841fe3f5--

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #24 from Andy Green  2010-04-13 12:21:23 PDT 
---
I can also confirm it's solved (and compiz!) well done.

However now I get overscan on the HDMI where I had 1:1 pixels before.

I guess it's a different bug if you don't have any hint.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff

2010-04-13 Thread Marcin Slusarz 
On Mon, Apr 12, 2010 at 11:33:27PM +0200, Marcin Slusarz wrote:
> > > > Have you got a pointer to a machine where it fails?
> > > 
> > > No, it failed with an artifical test while I was working on vga16fb 
> > > handoff
> > > (unfinished).
> > 
> > You won't be able to make this work for vga16fb from what I can see
> > since it access 0xa000 directly, not via any of the defined apertures
> > that vesafb/offb use. vga16fb will need a different approach I suspect.
> 
> Yeah, there's an idea to claim 0xa as an aperture of vga16fb and then
> do the same in KMS driver but only if it's the primary card. 
> (You hinted to use SHADOW resource bit to check whether card is primary)
> I think I'll try this approach soon.

Patch below works for me, but I couldn't test the case when nvidia card is 
secondary.

---
From: Marcin Slusarz 
Date: Tue, 13 Apr 2010 09:20:53 +0200
Subject: [PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff

let vga16fb claim 0xA+0x1 region as its aperture;
nouveau does not use it, so we need to lie to kick vga16fb,
but only if it's driving the primary card (by checking
IORESOURCE_ROM_SHADOW resource flag)

Signed-off-by: Marcin Slusarz 
---
 drivers/gpu/drm/nouveau/nouveau_state.c |   11 ++-
 drivers/video/vga16fb.c |   26 +++---
 2 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
b/drivers/gpu/drm/nouveau/nouveau_state.c
index cfa3239..a101861 100644
--- a/drivers/gpu/drm/nouveau/nouveau_state.c
+++ b/drivers/gpu/drm/nouveau/nouveau_state.c
@@ -636,10 +636,12 @@ static void nouveau_OF_copy_vbios_to_ramin(struct 
drm_device *dev)
 #endif
 }

+#define VGA_FB_PHYS 0xA
+#define VGA_FB_PHYS_LEN 65536
 static struct apertures_struct *nouveau_get_apertures(struct drm_device *dev)
 {
struct pci_dev *pdev = dev->pdev;
-   struct apertures_struct *aper = alloc_apertures(3);
+   struct apertures_struct *aper = alloc_apertures(4);
if (!aper)
return NULL;

@@ -658,6 +660,13 @@ static struct apertures_struct 
*nouveau_get_apertures(struct drm_device *dev)
aper->ranges[aper->count].size = pci_resource_len(pdev, 3);
aper->count++;
}
+   
+   /* if it's the primary card, claim 0xa as ours to kick vga16fb */
+   if (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_ROM_SHADOW) {
+   aper->ranges[aper->count].base = VGA_FB_PHYS;
+   aper->ranges[aper->count].size = VGA_FB_PHYS_LEN;
+   aper->count++;
+   }

return aper;
 }
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c
index 76d8dae..45d7a3d 100644
--- a/drivers/video/vga16fb.c
+++ b/drivers/video/vga16fb.c
@@ -1264,10 +1264,19 @@ static void vga16fb_imageblit(struct fb_info *info, 
const struct fb_image *image
vga_imageblit_color(info, image);
 }

+static void vga16fb_destroy(struct fb_info *info)
+{
+   iounmap(info->screen_base);
+   fb_dealloc_cmap(&info->cmap);
+   /* XXX unshare VGA regions */
+   framebuffer_release(info);
+}
+
 static struct fb_ops vga16fb_ops = {
.owner  = THIS_MODULE,
.fb_open= vga16fb_open,
.fb_release = vga16fb_release,
+   .fb_destroy = vga16fb_destroy,
.fb_check_var   = vga16fb_check_var,
.fb_set_par = vga16fb_set_par,
.fb_setcolreg   = vga16fb_setcolreg,
@@ -1307,6 +1316,11 @@ static int __devinit vga16fb_probe(struct 
platform_device *dev)
ret = -ENOMEM;
goto err_fb_alloc;
}
+   info->apertures = alloc_apertures(1);
+   if (!info->apertures) {
+   ret = -ENOMEM;
+   goto err_ioremap;
+   }

/* XXX share VGA_FB_PHYS and I/O region with vgacon and others */
info->screen_base = (void __iomem *)VGA_MAP_MEM(VGA_FB_PHYS, 0);
@@ -1336,7 +1350,7 @@ static int __devinit vga16fb_probe(struct platform_device 
*dev)
info->fix = vga16fb_fix;
/* supports rectangles with widths of multiples of 8 */
info->pixmap.blit_x = 1 << 7 | 1 << 15 | 1 << 23 | 1 << 31;
-   info->flags = FBINFO_FLAG_DEFAULT |
+   info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE |
FBINFO_HWACCEL_YPAN;

i = (info->var.bits_per_pixel == 8) ? 256 : 16;
@@ -1355,6 +1369,9 @@ static int __devinit vga16fb_probe(struct platform_device 
*dev)

vga16fb_update_fix(info);

+   info->apertures->ranges[0].base = VGA_FB_PHYS;
+   info->apertures->ranges[0].size = VGA_FB_PHYS_LEN;
+
if (register_framebuffer(info) < 0) {
printk(KERN_ERR "vga16fb: unable to register framebuffer\n");
ret = -EINVAL;
@@ -1381,13 +1398,8 @@ static int vga16fb_remove(struct platform_device *dev)
 {
struct fb_info *info = platform_get_drvdata(dev);

-   if (info) {
+   if (info)
unregister

[Bug 27402] [r300g] Earth textures in celestia are partially corrupted in all rendering paths

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=27402

--- Comment #10 from Chris Rankin  2010-04-13 
12:59:00 PDT ---
Earth textures are now completely missing in all rendering paths. Earth has
become Hoth.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #25 from Alex Deucher  2010-04-13 12:59:08 PDT 
---
(In reply to comment #24)
> However now I get overscan on the HDMI where I had 1:1 pixels before.

Did you change any settings on your TV?  Some TV's overscan by default unless
you disable it in the TV options.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #26 from Andy Green  2010-04-13 13:56:48 PDT 
---
Created an attachment (id=34978)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=34978)
Xorg log with overscanned HDMI out (no green cast!) on Aspire 8935

> Did you change any settings on your TV? 

No it's the same TV I used for some months; immediately before the kernel
upgrade it was showing 1:1 pixel 1920 x 1080 and after it's overscanned.

There's no setting for overscan in the TV's menu system either with HDMI input
source.

I attach the current /var/log/Xorg.0.log showing overscan, I previously
attached one that shows 1:1 pixels on the same laptop and TV.

I guess it can make sense to open a new bug, just wondering if there's a magic
Option somewhere to guide it not to overscan.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 26195] Green screen on HDMI with RV730

2010-04-13 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=26195

--- Comment #27 from Alex Deucher  2010-04-13 14:04:37 PDT 
---
(In reply to comment #26)
> No it's the same TV I used for some months; immediately before the kernel
> upgrade it was showing 1:1 pixel 1920 x 1080 and after it's overscanned.
> 
> There's no setting for overscan in the TV's menu system either with HDMI input
> source.
> 
> I attach the current /var/log/Xorg.0.log showing overscan, I previously
> attached one that shows 1:1 pixels on the same laptop and TV.
> 
> I guess it can make sense to open a new bug, just wondering if there's a magic
> Option somewhere to guide it not to overscan.

Yes, file a new bug.  Are you using hdmi audio or just video?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm_handle_t type

2010-04-13 Thread Robert Noland 
On Wed, 2010-04-14 at 00:19 +0100, Matthew W. S. Bell wrote:
> On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
> > On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
> > > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
> > > > Its probably not documented well anywhere, though I think the handles 
> > > > are
> > > > 32-bit is written down somewhere.
> > > 
> > > Ah sorry, I missed some.
> > 
> > drm_handle_t is correct here... 
> 
> No, drm_handle_t can be of a different size to void *; converting
> between integers and pointers of different sizes causes a warning. To
> eliminate the warning, the value first needs to be passed between
> uintptr_t and void *, which are of the same size, and then converted to
> drm_handle_t. The last part is implicit; the drm_handle_t casts are
> irrelevant/useless.

My point being that the casts to drm_handle_t are correct.  Feel free to
fix linux' define for drm_handle_t.

robert. 

> Matthew
-- 
Robert Noland 
2Hip Networks

[PATCH] drm_handle_t type

2010-04-13 Thread Robert Noland 
On Wed, 2010-04-14 at 00:19 +0100, Matthew W. S. Bell wrote:
> On Sun, 2010-04-11 at 09:10 -0500, Robert Noland wrote:
> > On Sat, 2010-04-10 at 19:30 +0100, Matthew W. S. Bell wrote:
> > > On Mon, 2010-04-05 at 17:46 +1000, Dave Airlie wrote:
> > > > Its probably not documented well anywhere, though I think the handles 
> > > > are
> > > > 32-bit is written down somewhere.
> > > 
> > > Ah sorry, I missed some.
> > 
> > drm_handle_t is correct here... 
> 
> No, drm_handle_t can be of a different size to void *; converting
> between integers and pointers of different sizes causes a warning. To
> eliminate the warning, the value first needs to be passed between
> uintptr_t and void *, which are of the same size, and then converted to
> drm_handle_t. The last part is implicit; the drm_handle_t casts are
> irrelevant/useless.

No, if you look at the BSD define for drm_handle_t, it does the right
thing on each arch.  The problem is that the linux define for
drm_handle_t is u32.

robert.

> Matthew
-- 
Robert Noland 
2Hip Networks