http://bugs.freedesktop.org/show_bug.cgi?id=25398
--- Comment #5 from Christopher Schramm 2009-12-04
23:31:04 PST ---
No, that didn't change anything (with radeon from git). In the radeon log
attached, I can see the bug you mentioned, when both are connected:
(II) RADEON(0): Output DVI-1 u
On Sat, Dec 5, 2009 at 3:33 PM, Luc Verhaegen wrote:
> On Sat, Dec 05, 2009 at 12:06:56AM -0500, Alex Deucher wrote:
>>
>> >
>> > But as long as you stick to your case religiously, then we are certain
>> > that all that crap was thrown justifiedly, even though connection
>> > detection always had
On Sat, Dec 05, 2009 at 12:06:56AM -0500, Alex Deucher wrote:
>
> >
> > But as long as you stick to your case religiously, then we are certain
> > that all that crap was thrown justifiedly, even though connection
> > detection always had to be some algorithm combining all available
> > information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Svilen wrote:
> Ian,
>
> Thanks again. It seems that we agree on the initialization sequence, but
> there are still some details - see below.
> On 12/04/2009 10:07 PM, Ian Romanick wrote:
>>
>>> 2. You call glXGetProcedureAddress to get the valid exis
On Fri, Dec 4, 2009 at 6:50 PM, Luc Verhaegen wrote:
> On Fri, Dec 04, 2009 at 06:14:24PM -0500, Alex Deucher wrote:
>> On Fri, Dec 4, 2009 at 5:58 PM, Luc Verhaegen wrote:
>> > On Fri, Dec 04, 2009 at 05:18:21PM -0500, Alex Deucher wrote:
>> >> This set of patches adds interrupt driven HPD (Hot
http://bugs.freedesktop.org/show_bug.cgi?id=22212
Joshua Roys changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=23545
maximlevit...@gmail.com changed:
What|Removed |Added
CC||maximlevit...@gmail.com
---
On Fri, Dec 04, 2009 at 06:14:24PM -0500, Alex Deucher wrote:
> On Fri, Dec 4, 2009 at 5:58 PM, Luc Verhaegen wrote:
> > On Fri, Dec 04, 2009 at 05:18:21PM -0500, Alex Deucher wrote:
> >> This set of patches adds interrupt driven HPD (Hot Plug Detect)
> >> support to r1xx-r7xx radeons. Assuming t
On Fri, Dec 4, 2009 at 5:58 PM, Luc Verhaegen wrote:
> On Fri, Dec 04, 2009 at 05:18:21PM -0500, Alex Deucher wrote:
>> This set of patches adds interrupt driven HPD (Hot Plug Detect)
>> support to r1xx-r7xx radeons. Assuming the HPD pin is wired up
>> correctly, the driver will generate uevents
http://bugs.freedesktop.org/show_bug.cgi?id=23545
--- Comment #8 from Maciej Cencora 2009-12-04 15:04:16
PST ---
I suspect the problem is with UMS texture manager, and I don't think that
anyone is willing to spend some time to work on this, so I recommend using the
KMS.
--
Configure bugm
On Fri, Dec 04, 2009 at 05:18:21PM -0500, Alex Deucher wrote:
> This set of patches adds interrupt driven HPD (Hot Plug Detect)
> support to r1xx-r7xx radeons. Assuming the HPD pin is wired up
> correctly, the driver will generate uevents for digital monitor
> connect and disconnect and will retra
Ian,
Thanks again. It seems that we agree on the initialization sequence, but
there are still some details - see below.
On 12/04/2009 10:07 PM, Ian Romanick wrote:
2. You call glXGetProcedureAddress to get the valid existing entry
points to the openGL procedures for the context you obtained
2009/12/4 Dave Airlie :
> On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote:
>> From: Zhao Yakui
>>
>> Disable all the possible outputs/crtcs before entering KMS mode.
>
> We need a bit more info than this for such a large change?
>
> At one point we wanted to do smooth startup for LVD
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Svilen wrote:
> On 12/03/2009 09:18 PM, Ian Romanick wrote:
>>> I was also a bit confused by the glewinfo report that the driver
>>> supports both glGenBuffers and glGenBuffersARB. It seems logical those
>>> two entry points to end-up with the same fun
This change allow driver to pass memory space preference
on buffer object placement. Up to 15 differents places
which should be enought. The placement order is given
by the memory type encoded on 4bits in 64bits dword.
First 4bits is the number of memory placement. Next
4bits is the prefered placem
This convert radeon to use new TTM validation API, it doesn't
really take advantage of it beside in the eviction case.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h|3 ++
drivers/gpu/drm/radeon/radeon_object.c | 56 +--
drivers/gpu/drm
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/drm_mm.c | 88 ++
include/drm/drm_mm.h | 34 ++
2 files changed, 122 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 97dc5a4..
This patch series implement first part of what i was describing in
a previous mail about ttm. Patches are not yet ready for inclusion
(need to finish commenting new fields & function and pass them
through checkpatch.pl), first patch is likely ready to go in.
It mostly allow driver to give a differ
On 12/03/2009 09:18 PM, Ian Romanick wrote:
>> It was another suggestion in the GLEW thread - that the graphic context
>> might be invalid. The application does have checks for this, but I'll
>> try to reconfirm with the user that this is not the case.
>>
> This is easy enough to test. Run t
On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote:
> From: Zhao Yakui
>
> Disable all the possible outputs/crtcs before entering KMS mode.
We need a bit more info than this for such a large change?
At one point we wanted to do smooth startup for LVDS panels,
so that we read back the
> On Fri, 04 Dec 2009 17:22:22 +0100
> Tobias Jakobi wrote:
>
>> Hi there,
>>
>> with a fresh git master from the libdrm repo compilation fails:
>>
>> make[3]: Entering directory
>> `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest'
>> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I.
On Fri, 04 Dec 2009 17:22:22 +0100
Tobias Jakobi wrote:
> Hi there,
>
> with a fresh git master from the libdrm repo compilation fails:
>
> make[3]: Entering directory
> `/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest'
> i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../..
Hi there,
with a fresh git master from the libdrm repo compilation fails:
make[3]: Entering directory
`/var/tmp/portage/x11-libs/libdrm-/work/libdrm-/tests/modetest'
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../..-I../../include/drm
-I../../intel/ -I../.. -I/usr/include/cairo -I/u
http://bugs.freedesktop.org/show_bug.cgi?id=25448
--- Comment #1 from Alex Deucher 2009-12-04 08:09:27 PST ---
Please attach your full xorg log and the output of:
LIBGL_DEBUG=verbose glxinfo
It sounds like you aren't getting 3D acceleration.
--
Configure bugmail: http://bugs.freedesktop.o
The the first patch properly sets the overscan regs on legacy hw which
fixes the display on some chips where the overscan regs aren't set up
properly. the second patch sets some common regs to sane default
values like the ddx does.
Alex
From abff20af66577a813cdd3e1046ee1703716bb8ab Mon Sep 17 00:
http://bugs.freedesktop.org/show_bug.cgi?id=24501
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=25448
Summary: mesa-7.7_rc1 & xf86-video-ati : low FPS, X11 restarts
after minimize/restore
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Sta
http://bugs.freedesktop.org/show_bug.cgi?id=25398
--- Comment #4 from Alex Deucher 2009-12-04 07:24:08 PST ---
Does disconnecting the monitor on DVI-1 (the Panasonic) help? There was a bug
in the xserver that did not handle field/frame size properly in some cases
which resulted in 1920x540
http://bugs.freedesktop.org/show_bug.cgi?id=25398
Alex Deucher changed:
What|Removed |Added
Attachment #31742|application/octet-stream|text/plain
mime type|
On Thu, Dec 3, 2009 at 8:08 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> Both radeon and nouveau can re-use this code so move it up a level
> so they can. However the hw interfaces for aux ch are different
> enough that the code to translate from mode, address, bytes
> to actual hw interfaces i
http://bugs.freedesktop.org/show_bug.cgi?id=25398
--- Comment #3 from Christopher Schramm 2009-12-04
07:17:15 PST ---
Created an attachment (id=31742)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31742)
Xorg log with radeon from current git
--
Configure bugmail: http://bugs.freede
http://bugs.freedesktop.org/show_bug.cgi?id=24611
--- Comment #16 from Alex Deucher 2009-12-04 07:08:13 PST ---
I wonder if this is the proper fix:
http://marc.info/?l=dri-devel&m=125986155228388&w=4
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are
http://bugzilla.kernel.org/show_bug.cgi?id=13683
--- Comment #31 from Alex Deucher 2009-12-04 15:05:46
---
Created an attachment (id=24023)
--> (http://bugzilla.kernel.org/attachment.cgi?id=24023)
possible fix
Can you try a kernel with the following patches?
http://git.kernel.org/?p=linux
Hello,
Here's the 2.4.16 release of libdrm. There are a lot of changes this
time, in particular we dropped the orphaned driver code from Linux and
BSD and this release is now really just libdrm. Going forward, the
drm header files we ship in libdrm will be a straight copy from the
linux kernel h
http://bugs.freedesktop.org/show_bug.cgi?id=25354
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=25398
--- Comment #2 from Alex Deucher 2009-12-04 06:29:30 PST ---
Can you attach your failing radeon log?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the
From: Zhao Yakui
Disable all the possible outputs/crtcs before entering KMS mode.
Signed-off-by: Zhao Yakui
---
drivers/gpu/drm/drm_crtc_helper.c | 32
include/drm/drm_crtc_helper.h |2 ++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git
http://bugzilla.kernel.org/show_bug.cgi?id=13683
--- Comment #30 from Jan Kreuzer 2009-12-04 14:05:13 ---
Sorry for replying late. I tested latest drm-radeon-next which contains your
patch. Unfortunately still the white screen, with and without r4xx_atom.
If you need more Information please
http://bugs.freedesktop.org/show_bug.cgi?id=25443
Summary: [nexuiz] Endless loading without kms
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medi
http://bugs.freedesktop.org/show_bug.cgi?id=23545
--- Comment #7 from Fabio 2009-12-04 01:46:01 PST ---
(In reply to comment #6)
> Can you check if the problem is still reproducible under KMS?
It isn't reproducible with KMS, even while running it with
MESA_EXTENSION_OVERRIDE=-GL_EXT_framebu
40 matches
Mail list logo
