[Bug 46802] Regnum online dont run on Shader model 2

https://bugs.freedesktop.org/show_bug.cgi?id=46802

Pablo <silpablo <at> hotmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|medium                      |low

--- Comment #1 from Pablo <silpablo <at> hotmail.com> 2012-02-29 19:36:11 PST ---
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD RV730
OpenGL version string: 2.1 Mesa 8.1-devel (git-897af1d)
OpenGL shading language version string: 1.20

I've added an screenshot

--

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

[Bug 46802] Regnum online dont run on Shader model 2

https://bugs.freedesktop.org/show_bug.cgi?id=46802

--- Comment #2 from Pablo <silpablo <at> hotmail.com> 2012-02-29 19:42:55 PST ---
Created attachment 57843
  --> https://bugs.freedesktop.org/attachment.cgi?id=57843
static image in sm2

--

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

Re: [PATCH] i915: Add option to bypass vbt table.

Hi,

On Wednesday, February 29, 2012 22:04:45 you wrote:
> thank you for your patch. Could you please resend it as [PATCH v2] with
> the following things addressed.
Will do. Thanks!

Mathias

[PATCH v2] i915: Add option to bypass vbt table.

From: Mathias Fröhlich <Mathias.Froehlich <at> web.de>

Add an option to skip reading the mode entries from
the vbt bios tables.
This change enables the use of displays where the vbt table just
contains inappropriate values, but either the vesa defaults or
the video=... modes do something sensible with the attached display.

Reviewed-by: Paul Menzel <paulepanter <at> users.sourceforge.net>
Signed-off-by: Mathias Froehlich <Mathias.Froehlich <at> web.de>
---
 drivers/gpu/drm/i915/i915_drv.c   |    4 ++--
 drivers/gpu/drm/i915/intel_bios.c |    5 +++++
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 308f819..0975895 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
 <at>  <at>  -89,8 +89,8  <at>  <at>  MODULE_PARM_DESC(lvds_use_ssc,
 int i915_vbt_sdvo_panel_type __read_mostly = -1;
 module_param_named(vbt_sdvo_panel_type, i915_vbt_sdvo_panel_type, int, 0600);
 MODULE_PARM_DESC(vbt_sdvo_panel_type,
-		"Override selection of SDVO panel mode in the VBT "
-		"(default: auto)");
+		"Override/Ignore selection of SDVO panel mode in the VBT "
+		"(-2=ignore, -1=auto [default], index in VBT BIOS table)");

 static bool i915_try_reset __read_mostly = true;
 module_param_named(reset, i915_try_reset, bool, 0600);

[korg]help: How to submit a kernel driver on kernel.org.

_______________________________________________
dri-devel mailing list
dri-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: regression(?) 3.3-rc4 -> 3.3-rc5: drm intel hangs

Hi everyone,

sorry for the late answer, I was sure that it does not happen again,
but alas, right then, it happened again.

On Di, 28 Feb 2012, Paul Menzel wrote:
> I do not know. But it would be interesting to know if you just see this
> in your log files or if you also see some effects like screen
> corruptions. You can increase the log level by adding `drm.debug=0x06`
> to the Linux kernel command line [1].

Yes: - gnome-screensaver dialog does not come up
- former case: fall back to gnome3 fallback mode, no 3d accel

I didn't have the drm.debug=0x06 running, but with the next reboot
I will activate it and hope it happens again.

On Di, 28 Feb 2012, Dave Airlie wrote:
> And you haven't changed userspace in any way?

On 25. Februar I got the new version of Debian's
	xserver-xorg-video-intel 2.18.0
	debian 2:2.18.0-1
updated from 2:2.17.0-1

Anything I can do to blame this on user space?

On Di, 28 Feb 2012, Daniel Vetter wrote:
> Wee need this i915_error_state file from debugfs (you might need to mount
> that first again) to diagnose gpu hangs. Also, it only contains
> information after a crash, so you need to rehang your machine if you've
> rebooted since then.

I didn't have debugfs mounted when it crashed, though ....
I mounted it *afterwards* and attach the i915_error_state file.
Mind, there is also a /debugfs/dri/64/ directory with a i915_error_state,
but they are absolutely the same.

If I have to have debugfs *monted* at the time of the crash, I have to
wait for the next instance.

Best wishes

Norbert
------------------------------------------------------------------------
Norbert Preining            preining <at> {jaist.ac.jp, logic.at, debian.org}
JAIST, Japan                                 TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
GUERNSEY (adj.)
			--- Douglas Adams, The Meaning of Liff

‹'OO

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

--
_______________________________________________
Dri-devel mailing list
Dri-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 46796] [X800SE] Mouse cursor corruption when switching users

https://bugs.freedesktop.org/show_bug.cgi?id=46796

Michel Dänzer <michel <at> daenzer.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|xorg-driver-ati <at> lists.x.org |dri-devel <at> lists.freedesktop
                   |                            |.org
          QAContact|xorg-team <at> lists.x.org       |
            Product|xorg                        |DRI
          Component|Driver/Radeon               |DRM/Radeon

--

-- 
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 <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block

On Sun, Nov 13, 2011 at 02:04:54AM +0100, Christian Schmidt wrote:
> The current logic misunderstands the spec about CEA 18byte descriptors.
> First, the spec doesn't state "detailed timing descriptors" but "18 byte
> descriptors", so any data record could be stored, mixed timings and
> other data, just as in the standard EDID.
> Second, the lower four bit of byte 3 of the CEA record do not contain
> the number of descriptors, but "the total number of DTDs defining native
> formats in the whole EDID [...], starting with the first DTD in the DTD
> list (which starts in the base EDID block)." A device can of course
> support non-native formats.
> 
> As such the number can't be used to determine n, and the existing code
> will filter non-timing 18byte descriptors anyway.
> 
> Signed-off-by: Christian Schmidt <schmidt <at> digadd,de>

> diff -ur linux-3.2-rc1.orig/drivers/gpu/drm/drm_edid.c linux-3.2-rc1/drivers/gpu/drm/drm_edid.c
> --- linux-3.2-rc1.orig/drivers/gpu/drm/drm_edid.c	2011-11-13 01:42:29.771092473 +0100
> +++ linux-3.2-rc1/drivers/gpu/drm/drm_edid.c	2011-11-13 01:54:32.031062983 +0100
>  <at>  <at>  -511,22 +511,7  <at>  <at> 
>  	u8 rev = ext[0x01], d = ext[0x02];
>  	u8 *det_base = ext + d;
>  
> -	switch (rev) {
> -	case 0:
> -		/* can't happen */
> -		return;
> -	case 1:
> -		/* have to infer how many blocks we have, check pixel clock */
> -		for (i = 0; i < 6; i++)
> -			if (det_base[18*i] || det_base[18*i+1])
> -				n++;
> -		break;
> -	default:
> -		/* explicit count */
> -		n = min(ext[0x03] & 0x0f, 6);
> -		break;
> -	}
> -
> +	n = (127 - d) / 18;
>  	for (i = 0; i < n; i++)
>  		cb((struct detailed_timing *)(det_base + 18 * i), closure);
>  }

I just stumbled on this same thing when looking at some internal patch.

Looks good, except you should also check that 'd' is less than 127.
I do wonder how may other unchecked buffer accesses there are in the
EDID code...

--

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH] Fix wrong assumptions in cea_for_each_detailed_block

On Thu, Mar 01, 2012 at 01:53:01PM +0200, Ville Syrjälä wrote:
> On Sun, Nov 13, 2011 at 02:04:54AM +0100, Christian Schmidt wrote:
> > The current logic misunderstands the spec about CEA 18byte descriptors.
> > First, the spec doesn't state "detailed timing descriptors" but "18 byte
> > descriptors", so any data record could be stored, mixed timings and
> > other data, just as in the standard EDID.
> > Second, the lower four bit of byte 3 of the CEA record do not contain
> > the number of descriptors, but "the total number of DTDs defining native
> > formats in the whole EDID [...], starting with the first DTD in the DTD
> > list (which starts in the base EDID block)." A device can of course
> > support non-native formats.
> > 
> > As such the number can't be used to determine n, and the existing code
> > will filter non-timing 18byte descriptors anyway.
> > 
> > Signed-off-by: Christian Schmidt <schmidt <at> digadd,de>
> 
> > diff -ur linux-3.2-rc1.orig/drivers/gpu/drm/drm_edid.c linux-3.2-rc1/drivers/gpu/drm/drm_edid.c
> > --- linux-3.2-rc1.orig/drivers/gpu/drm/drm_edid.c	2011-11-13 01:42:29.771092473 +0100
> > +++ linux-3.2-rc1/drivers/gpu/drm/drm_edid.c	2011-11-13 01:54:32.031062983 +0100
> >  <at>  <at>  -511,22 +511,7  <at>  <at> 
> >  	u8 rev = ext[0x01], d = ext[0x02];
> >  	u8 *det_base = ext + d;
> >  
> > -	switch (rev) {
> > -	case 0:
> > -		/* can't happen */
> > -		return;
> > -	case 1:
> > -		/* have to infer how many blocks we have, check pixel clock */
> > -		for (i = 0; i < 6; i++)
> > -			if (det_base[18*i] || det_base[18*i+1])
> > -				n++;
> > -		break;
> > -	default:
> > -		/* explicit count */
> > -		n = min(ext[0x03] & 0x0f, 6);
> > -		break;
> > -	}
> > -
> > +	n = (127 - d) / 18;
> >  	for (i = 0; i < n; i++)
> >  		cb((struct detailed_timing *)(det_base + 18 * i), closure);
> >  }
> 
> I just stumbled on this same thing when looking at some internal patch.
> 
> Looks good, except you should also check that 'd' is less than 127.
> I do wonder how may other unchecked buffer accesses there are in the
> EDID code...

Ah, didn't realize this was in already. I was looking at an older tree.

I'll send a patch to do the bounds checking...

--

-- 
Ville Syrjälä
Intel OTC

[PATCH] drm: edid: Add bounds checking to CEA 18 byte descriptor parsing

From: Ville Syrjälä <ville.syrjala <at> linux.intel.com>

Make sure we don't access beyond the extension block when parsing CEA
detailed timing descriptors.

Signed-off-by: Ville Syrjälä <ville.syrjala <at> linux.intel.com>
---
 drivers/gpu/drm/drm_edid.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..0194d4a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
 <at>  <at>  -516,6 +516,9  <at>  <at>  cea_for_each_detailed_block(u8 *ext, detailed_cb *cb, void *closure)
 	u8 d = ext[0x02];
 	u8 *det_base = ext + d;

+	if (d > 127)
+		return;
+
 	n = (127 - d) / 18;
 	for (i = 0; i < n; i++)
 		cb((struct detailed_timing *)(det_base + 18 * i), closure);
--

-- 
1.7.3.4

_______________________________________________
dri-devel mailing list
dri-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel