On Monday 16. January 2012 21:30:59 Jerome Glisse wrote:
> On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> > In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
> > at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough to
> > reproduce, so I ca
On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark wrote:
> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
> wrote:
>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
>>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>>> wrote:
On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark
wrote:
>>
On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
> Some decent history digging indicates that this was to be used for the
> GLX_MESA_allocate_memory extension but never actually implemented for
> any released i915 userspace code.
>
> So just rip it out.
>
> Cc: Dave Airlie
> Cc: Ke
FB based FIMD and DRM based FIMD drivers use same hardware
so with this patch, only one of them would be selected.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ex
I'd like to add my colleagues who dedicated to developing and
improving our driver to maintainer entry.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
MAINTAINERS |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1094edf..1ec0d9
From: Seung-Woo Kim
DRM_EXYNOS_HDMI driver and VIDEO_SAMSUNG_S5P_TV driver should be
not enabled at once because they use same HW blocks. So dependency
for DRM_EXYNOS_HDMI is fixed to check VIDEO_SAMSUNG_S5P_TV=n.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Par
From: Seung-Woo Kim
To make a api pair of request_mem_region and release_mem_region,
release_mem_region is used instead of release_resource.
Signed-off-by: Seung-Woo Kim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c |8
1 files cha
this patch set fixes the issues that two drivers use same hardware, FIMD and
HDMI,
and also I'd like to add my colleagues who dedicated to developing and improving
Exynos DRM Driver to maintainer entry.
this is based on git repository below:
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/d
Hi Dave,
Is it ok if I merge this through my -next tree? Otherwise please consider
merging this for 3.4.
Yours, Daniel
On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-responding bus repeatedly until we
> finally timeout after 15 attempts. W
Hi all,
Because Keith is routinely really busy with all kinds of things, notably
gathering fixes for drm-intel-fixes, the patch merge process for the next
release cycle sometimes falls behind. To support him and improve things I've
been volunteered to take over handling the -next tree.
The main
https://bugzilla.kernel.org/show_bug.cgi?id=42580
J?r?me Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=43698
--- Comment #12 from GhostlyDeath 2012-01-16
12:36:30 PST ---
I still get rendering errors with PrBoom with the patch applied. Do you have a
complete patch that can be applied to a more recent git revision?
By the way, I rebuilt with:
# make cl
On Mon, Jan 16, 2012 at 7:59 PM, Paulo Zanoni wrote:
> Hi
>
> 2012/1/5 Jakob Bornecrantz :
>> Couldn't this be done by just adding a property instead of a ioctl?
>>
>
> So I've discussed this with Jesse and it seems the best way to turn
> this into a property is to add support for CRTC properties,
https://bugzilla.kernel.org/show_bug.cgi?id=42580
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
--- Comment
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #9 from Marko Kohtala 2012-01-16
11:43:20 PST ---
Created attachment 55651
--> https://bugs.freedesktop.org/attachment.cgi?id=55651
Artefacts in X, screencapture
This capture was with the enable_mtrr_cleanup mtrr_spare_reg_nr=1 to
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #8 from Marko Kohtala 2012-01-16
11:26:00 PST ---
Created attachment 55650
--> https://bugs.freedesktop.org/attachment.cgi?id=55650
dmesg with enable_mtrr_cleanup
Attached the dmesg with The /proc/mtrr is
reg00: base=0x0
On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
> wrote:
>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
>>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>> wrote:
On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark
wrote:
>>
2012/1/16 Dave Airlie :
>
> Okay I must have missed the bit where you explain why a connector
> property isn't used?
The registers that contain the rotation information are the pipe
registers and, as far as I understood, each pipe is associated with
only one crtc. We can have more than one connect
Three comments about the design are inline:
> +void drm_crtc_attach_property(struct drm_crtc *crtc,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct drm_property *property, uint64_t
> init_val)
> +{
> + ? ? ? int i;
> +
> + ? ? ? for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++) {
> + ? ? ? ? ? ? ? if (crtc->pro
From: Paulo Zanoni
This property is needed by to inform the KVMr feature about our
current rotation: whenever we change the rotation, we should change
that property so that the KVMr knows that the screen is rotated.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h |5 ++
From: Paulo Zanoni
Code based on the connector properties code.
Two new ioctls:
- DRM_IOCTL_MODE_CRTC_GETPROPERTIES
- DRM_IOCTL_MODE_CRTC_SETPROPERTY
The i915 driver needs this (for the rotation property). Other drivers
might need this too.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm
From: Paulo Zanoni
Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_crtc.c | 41 +
1 files changed, 21 insertions(+), 20 d
Hi
2012/1/5 Jakob Bornecrantz :
> Couldn't this be done by just adding a property instead of a ioctl?
>
So I've discussed this with Jesse and it seems the best way to turn
this into a property is to add support for CRTC properties, then add a
"rotation" property for the i915 driver. This will act
On Mon, Jan 16, 2012 at 17:41, Daniel Vetter wrote:
>
> Hi all,
>
> Because Keith is routinely really busy with all kinds of things, notably
> gathering fixes for drm-intel-fixes, the patch merge process for the next
> release cycle sometimes falls behind. To support him and improve things I've
>
https://bugs.freedesktop.org/show_bug.cgi?id=44848
Bug #: 44848
Summary: OpenArena brightness control does not work
Classification: Unclassified
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #18 from Valter 2012-01-16
09:22:40 PST ---
Hello to everybody, again.
I stand corrected.
After further tests, after rebooting, it is sufficient only to give the
command:
xrandr - output DVI-0 - mode 1920x1080R
so that the monito
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #9 from smoki 2012-01-16 16:37:29 UTC ---
Created attachment 55656
--> https://bugs.freedesktop.org/attachment.cgi?id=55656
oprofiled fog
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are r
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #9 from smoki 2012-01-16 16:37:29 UTC ---
Created attachment 55656
--> https://bugs.freedesktop.org/attachment.cgi?id=55656
oprofiled fog
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are r
https://bugs.freedesktop.org/show_bug.cgi?id=44499
--- Comment #8 from smoki 2012-01-16 16:36:23 PST ---
Created attachment 55655
--> https://bugs.freedesktop.org/attachment.cgi?id=55655
oprofiled blender
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You a
On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
> wrote:
>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark wrote:
>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>>> index 9a58461..b86e6cb 100644
>>> --- a/arch/arm/pl
On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
> at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough to
> reproduce, so I can test patches if needed.
>
> Martin
>
How do you trigge
On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
wrote:
> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark wrote:
>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>> wrote:
>>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=36441
--- Comment #8 from Alex Deucher 2012-01-16 06:16:23 PST
---
Is this still an issue on newer versions of r600g?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
https://bugs.freedesktop.org/show_bug.cgi?id=36441
--- Comment #7 from Tom Simnett 2012-01-16
05:40:18 PST ---
Created attachment 55636
--> https://bugs.freedesktop.org/attachment.cgi?id=55636
artefacts under -nouveau
This appears to happen in -nouveau too. Screenshot attached. What additiona
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #17 from Valter 2012-01-16
05:39:36 PST ---
Ok.
I made ??the suggestion of Alex in this way:
1) I gave the following terminal commands:
xrandr - newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 +
hsync-vsync
xrand
On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
wrote:
> On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark wrote:
>> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
>> wrote:
>>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
wrote:
On Thu, Dec 22, 2011 at 10:23:14PM +0100, Daniel Vetter wrote:
> Some decent history digging indicates that this was to be used for the
> GLX_MESA_allocate_memory extension but never actually implemented for
> any released i915 userspace code.
>
> So just rip it out.
>
> Cc: Dave Airlie
> Cc: Ke
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c |2 +-
drivers/staging/omapdrm/omap_drv.h |6 ++
drivers/staging/omapdrm/omap_plane.c | 33 -
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/driver
From: Rob Clark
Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12). Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinn
From: Rob Clark
Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 30 +-
drivers/staging/omapdrm/omap_fb.c| 103 ++
drivers/staging/omapdr
From: Rob Clark
Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
From: Rob Clark
Now that drm and fbdev (omapdss) next trees have been pulled by Linus,
here are the updates to keep omapdrm compiling.
The first four are re-sends of what was sent earlier, and the fifth
takes care of some API changes in omapdss contained in the fbdev pull.
Rob Clark (5):
drm/
2012/1/16 Dave Airlie :
>
> Okay I must have missed the bit where you explain why a connector
> property isn't used?
The registers that contain the rotation information are the pipe
registers and, as far as I understood, each pipe is associated with
only one crtc. We can have more than one connect
On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark wrote:
> On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
> wrote:
>> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
>>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>>> wrote:
On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
> On
https://bugzilla.kernel.org/show_bug.cgi?id=42580
Jérôme Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=43698
--- Comment #12 from GhostlyDeath 2012-01-16 12:36:30
PST ---
I still get rendering errors with PrBoom with the patch applied. Do you have a
complete patch that can be applied to a more recent git revision?
By the way, I rebuilt with:
# make cl
On Mon, Jan 16, 2012 at 7:59 PM, Paulo Zanoni wrote:
> Hi
>
> 2012/1/5 Jakob Bornecrantz :
>> Couldn't this be done by just adding a property instead of a ioctl?
>>
>
> So I've discussed this with Jesse and it seems the best way to turn
> this into a property is to add support for CRTC properties,
Hi Dave,
Is it ok if I merge this through my -next tree? Otherwise please consider
merging this for 3.4.
Yours, Daniel
On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote:
> This allows to avoid talking to a non-responding bus repeatedly until we
> finally timeout after 15 attempts. W
Three comments about the design are inline:
> +void drm_crtc_attach_property(struct drm_crtc *crtc,
> + struct drm_property *property, uint64_t
> init_val)
> +{
> + int i;
> +
> + for (i = 0; i < DRM_CRTC_MAX_PROPERTY; i++) {
> + if (crtc->pro
https://bugzilla.kernel.org/show_bug.cgi?id=42580
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
--- Comment #1
On Sun, Jan 15, 2012 at 10:31:08PM +0100, Martin Nyhus wrote:
> In some cases mem will be null in nouveau_vm_map_sg, resulting in a crash
> at drivers/gpu/drm/nouveau/nouveau_vm.c:84. It seems to be easy enough to
> reproduce, so I can test patches if needed.
>
> Martin
>
How do you trigge
From: Paulo Zanoni
This property is needed by to inform the KVMr feature about our
current rotation: whenever we change the rotation, we should change
that property so that the KVMr knows that the screen is rotated.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h |5 ++
From: Paulo Zanoni
Code based on the connector properties code.
Two new ioctls:
- DRM_IOCTL_MODE_CRTC_GETPROPERTIES
- DRM_IOCTL_MODE_CRTC_SETPROPERTY
The i915 driver needs this (for the rotation property). Other drivers
might need this too.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm
From: Paulo Zanoni
Move code from drm_mode_connector_property_set_ioctl to a new
function, so we can reuse this code when we add crtc properties.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/drm_crtc.c | 41 +
1 files changed, 21 insertions(+), 20 d
Hi
2012/1/5 Jakob Bornecrantz :
> Couldn't this be done by just adding a property instead of a ioctl?
>
So I've discussed this with Jesse and it seems the best way to turn
this into a property is to add support for CRTC properties, then add a
"rotation" property for the i915 driver. This will act
On Mon, Jan 16, 2012 at 17:41, Daniel Vetter wrote:
>
> Hi all,
>
> Because Keith is routinely really busy with all kinds of things, notably
> gathering fixes for drm-intel-fixes, the patch merge process for the next
> release cycle sometimes falls behind. To support him and improve things I've
>
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #9 from Marko Kohtala 2012-01-16 11:43:20
PST ---
Created attachment 55651
--> https://bugs.freedesktop.org/attachment.cgi?id=55651
Artefacts in X, screencapture
This capture was with the enable_mtrr_cleanup mtrr_spare_reg_nr=1 to
Hi all,
Because Keith is routinely really busy with all kinds of things, notably
gathering fixes for drm-intel-fixes, the patch merge process for the next
release cycle sometimes falls behind. To support him and improve things I've
been volunteered to take over handling the -next tree.
The main
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #8 from Marko Kohtala 2012-01-16 11:26:00
PST ---
Created attachment 55650
--> https://bugs.freedesktop.org/attachment.cgi?id=55650
dmesg with enable_mtrr_cleanup
Attached the dmesg with The /proc/mtrr is
reg00: base=0x0
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #7 from Michel D?nzer 2012-01-16 03:23:43
PST ---
The panic backtrace doesn't look obviously related to the radeon driver ? all
the symptoms sound like something might be scribbling more or less randomly
over memory.
I wonder if the
On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
wrote:
> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>> wrote:
>>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
wrote:
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c |2 +-
drivers/staging/omapdrm/omap_drv.h |6 ++
drivers/staging/omapdrm/omap_plane.c | 33 -
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/driver
From: Rob Clark
Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12). Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinn
From: Rob Clark
Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 30 +-
drivers/staging/omapdrm/omap_fb.c| 103 ++
drivers/staging/omapdr
From: Rob Clark
Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
From: Rob Clark
Now that drm and fbdev (omapdss) next trees have been pulled by Linus,
here are the updates to keep omapdrm compiling.
The first four are re-sends of what was sent earlier, and the fifth
takes care of some API changes in omapdss contained in the fbdev pull.
Rob Clark (5):
drm/
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #16 from Michel D?nzer 2012-01-16 02:43:18
PST ---
(In reply to comment #15)
> X Error of failed request: BadName (named color or font does not exist)
> Major opcode of failed request: 150 (RANDR)
> Minor opcode of failed reque
On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
wrote:
> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark wrote:
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #18 from Valter 2012-01-16 09:22:40
PST ---
Hello to everybody, again.
I stand corrected.
After further tests, after rebooting, it is sufficient only to give the
command:
xrandr - output DVI-0 - mode 1920x1080R
so that the monito
On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
wrote:
> On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
>> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
>> wrote:
>>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
wrote:
On Mon, Jan 16, 2012 at 6:37 PM, Rob Clark wrote:
> On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
> wrote:
>> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
>>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>>> wrote:
On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark wrote:
> di
On Mon, Jan 16, 2012 at 8:12 AM, Felipe Contreras
wrote:
> On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
>> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
>> wrote:
>>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark wrote:
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/
https://bugs.freedesktop.org/show_bug.cgi?id=36441
--- Comment #8 from Alex Deucher 2012-01-16 06:16:23 PST ---
Is this still an issue on newer versions of r600g?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You
On Fri, Jan 13, 2012 at 11:19 PM, Rob Clark wrote:
> On Fri, Jan 13, 2012 at 2:59 PM, Felipe Contreras
> wrote:
>> On Fri, Jan 13, 2012 at 10:41 PM, Rob Clark wrote:
>>> diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
>>> index 9a58461..b86e6cb 100644
>>> --- a/arch/arm/pl
https://bugs.freedesktop.org/show_bug.cgi?id=36441
--- Comment #7 from Tom Simnett 2012-01-16
05:40:18 PST ---
Created attachment 55636
--> https://bugs.freedesktop.org/attachment.cgi?id=55636
artefacts under -nouveau
This appears to happen in -nouveau too. Screenshot attached. What additiona
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #17 from Valter 2012-01-16 05:39:36
PST ---
Ok.
I made the suggestion of Alex in this way:
1) I gave the following terminal commands:
xrandr - newmode "1920x1080R" 138.50 1920 1968 2000 2080 1080 1083 1088 +
hsync-vsync
xrand
https://bugs.freedesktop.org/show_bug.cgi?id=44800
--- Comment #7 from Michel Dänzer 2012-01-16 03:23:43 PST
---
The panic backtrace doesn't look obviously related to the radeon driver — all
the symptoms sound like something might be scribbling more or less randomly
over memory.
I wonder if the
https://bugs.freedesktop.org/show_bug.cgi?id=43858
--- Comment #16 from Michel Dänzer 2012-01-16 02:43:18 PST
---
(In reply to comment #15)
> X Error of failed request: BadName (named color or font does not exist)
> Major opcode of failed request: 150 (RANDR)
> Minor opcode of failed reque
80 matches
Mail list logo
