Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Jesse Barnes <jbarnes@vi...>]

It would help to know what the server is doing at this point with the
client.  It may be that it put the client to sleep and hasn't woken it
up yet, or there could be something wrong with our getbuffers code in
the new scheme.

Jesse

On Sat, 06 Mar 2010 18:02:51 +0100
Stephan Raue <mailinglists@...> wrote:

> looks this like my problems that i have reported some days ago with 
> Subject "Problem using an Mesa based App with recent 
> xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> 
> i have still this issue, but i dont know what you need for informations 
> to fix the issues?
> 
> with ati driver i dont have problems, only here with intel driver on my 
> Thinkpad X200t with intel HDA Graphics card
> 
> Stephan
> 
> Am 06.03.2010 17:46, schrieb Maxim Levitsky:
> > On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
> >    
> >> On Sat, 06 Mar 2010 16:40:27 +0200
> >> Maxim Levitsky<maximlevitsky@...>  wrote:
> >>
> >>      
> >>> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote:
> >>>        
> >>>> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> >>>>          
> >>>>> On Fri, 05 Mar 2010 23:48:48 +0200
> >>>>> Maxim Levitsky<maximlevitsky@...>  wrote:
> >>>>>
> >>>>>            
> >>>>>> On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote:
> >>>>>>              
> >>>>>>> On Fri, 05 Mar 2010 23:18:07 +0200
> >>>>>>> Maxim Levitsky<maximlevitsky@...>  wrote:
> >>>>>>>
> >>>>>>>                
> >>>>>>>> On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote:
> >>>>>>>>                  
> >>>>>>>>> On Fri, 05 Mar 2010 22:42:21 +0200
> >>>>>>>>> Maxim Levitsky<maximlevitsky@...>  wrote:
> >>>>>>>>>
> >>>>>>>>>                    
> >>>>>>>>>> After quite long period of inactivity, I updated graphical stack on my
> >>>>>>>>>> desktop/server.
> >>>>>>>>>>
> >>>>>>>>>> To say the truth, I did such update about month ago, but found out that
> >>>>>>>>>> X refuses flatly to use DRI modules. I assumed that it was my mistake in
> >>>>>>>>>> compilation process (although it is automated).
> >>>>>>>>>>                      
> >>>>>>>>> That generally indicates a build or config problem of some kind.  Did
> >>>>>>>>> you ever narrow it down?
> >>>>>>>>>                    
> >>>>>>>> Because the same compile process works now, I suspect that wasn't build
> >>>>>>>> failure.
> >>>>>>>>                  
> >>>>>>> Well something weird is going on; maybe you didn't build X after Mesa
> >>>>>>> or with the right Mesa includes?
> >>>>>>>                
> >>>>>> I am very sure that this issue isn't relevant now.
> >>>>>>
> >>>>>> I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in
> >>>>>> that order, compiling everything from scratch (doing git clean -dfx in
> >>>>>> all directories)
> >>>>>>              
> >>>>> if you just want a working setup, perhaps you should try using
> >>>>> something that got (probably) tested by at least some people:
> >>>>>   	http://intellinuxgraphics.org/2009Q4.html
> >>>>> cheers,
> >>>>> Flo
> >>>>>            
> >>>> Well, I now have a working setup with mesa
> >>>> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> >>>>
> >>>> The problem is that I hoped that once all heavy work in regard to KMS
> >>>> was done, there will be no serious regressions in 3D stack, but only bug
> >>>> fixes, because it is very hard to track and fix bugs there.
> >>>>
> >>>> However, once again 3D stack is in bad shape, and this is not good.
> >>>>          
> >>>
> >>> More testing shows the following behaviour:
> >>>
> >>>
> >>>
> >>> Full screen mode is completely busted. As soon as any 3D application
> >>> switches to full screen mode, even without changing the resolution, it
> >>> hangs (note that I didn't see GPU hangs due to that)
> >>>
> >>> Compiz is broken (its also a full screen app...). As soon as it starts,
> >>> it draws few windows, and then stalls.
> >>>
> >>> In window mode all applications do work.
> >>>
> >>>
> >>> Now I guess this is worth a bugzilla entry.
> >>> (If this isn't there yet...)
> >>>        
> >> I'm not seeing this on GM45.  I just installed a totally fresh stack on
> >> a new F12 installation and compiz and games work well.  But please file
> >> a bug and include everything needed (see intellinuxgraphics.org for the
> >> list); hope we can find the issue.
> >>      
> >
> > Here, gdb backtrace while running sauerbraten full screen:
> >
> >
> > #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
> > #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> > #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
> > #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
> >      outCount=0xbfc6a608) at dri2.c:428
> > #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
> >      loaderPrivate=0x93eecb0) at dri2_glx.c:435
> > #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
> > #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
> > #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
> >      min_index=0, max_index=3) at brw_draw.c:340
> > #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
> >      at brw_draw.c:441
> > #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
> > #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
> > #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
> > #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
> > #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
> > #16 0x080abf08 in ?? ()
> > #17 0x080ad3fc in ?? ()
> > #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
> >
> >
> > Best regards,
> > 	Maxim Levitsky
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@...
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >    
> 
> 


-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 26927] Blank LVDS Dell Studio 17

[<bugzilla-daemon@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26927





--- Comment #3 from Alex Deucher <agd5f@...>  2010-03-06 15:08:11 PST ---
Can you attach the output of lspci -vnn and your video bios?  To dump your
video bios do the following (as root):
cd /sys/bus/pci/devices/<pci bus id>
echo 1 > rom
cat rom > /tmp/vbios.rom
echo 0 > rom


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

Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Florian Mickler <florian@mi...>]

On Sun, 07 Mar 2010 00:24:24 +0200
Maxim Levitsky <maximlevitsky@...> wrote:

> On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> > On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > > On Sat, 06 Mar 2010 18:02:51 +0100
> > > Stephan Raue <mailinglists@...> wrote:
> > > 
> > > > looks this like my problems that i have reported some days ago with 
> > > > Subject "Problem using an Mesa based App with recent 
> > > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > > 
> > > > i have still this issue, but i dont know what you need for informations 
> > > > to fix the issues?
> > > > 
> > > > with ati driver i dont have problems, only here with intel driver on my 
> > > > Thinkpad X200t with intel HDA Graphics card
> > > > 
> > 
> > I now see that compiz hangs in same way.
> > 
> > Attached are backtrace of the compiz, and backtrace of etracer which did
> > start full screen but became hung on resolution change.
> > 
> > Best regards,
> > 	Maxim Levitsky
> 
> Other info that might help:
> 
> I took a look at X and found that it was in normal waiting state
> sleeping waiting for input.
> 
> Also, I found when 'unstable' mesa would appear to work when I start the
> X while 'stable' one is used. It was compiz. When compiz is running
> using stable mesa, an game does change the resolution 'usualy' without
> hang even if uses unstable mesa.
> 
> Best regards,
> 	Maxim Levitsky

i found that the kernel updates for 2.6.34-rc1 did make the hang time
out... this has to be some vblank issue, i assume...

Re: [git pull] drm request 3

[<tytso@mi...>]

On Sat, Mar 06, 2010 at 08:52:35PM +0000, Alan Cox wrote:
> > They want the benefits of lots of testers, without wanting to be
> > courteous to those testers.
> 
> Except for the small rather important detail that the Nouveau developers
> didn't ask for it to be merged in the first place.
> 

*Someone* on the Red Hat/Fedora team made the decision to make it
available on a very popular distribution to get more testing.  And
they did it without putting in the necessary versioning so that kernel
testers could test upstream kernels.  That, in my book, is an
anti-social thing to do.  Fedora isn't alone, of course; Ubuntu does
this as well, and worse yet, with proprietary binary drivers.  But
just because Ubuntu does something worse, doesn't mean that Fedora
should get a free pass for what they did.

						- Ted

Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Maxim Levitsky <maximlevitsky@gm...>]

On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> > On Sat, 06 Mar 2010 18:02:51 +0100
> > Stephan Raue <mailinglists@...> wrote:
> > 
> > > looks this like my problems that i have reported some days ago with 
> > > Subject "Problem using an Mesa based App with recent 
> > > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > > 
> > > i have still this issue, but i dont know what you need for informations 
> > > to fix the issues?
> > > 
> > > with ati driver i dont have problems, only here with intel driver on my 
> > > Thinkpad X200t with intel HDA Graphics card
> > > 
> 
> I now see that compiz hangs in same way.
> 
> Attached are backtrace of the compiz, and backtrace of etracer which did
> start full screen but became hung on resolution change.
> 
> Best regards,
> 	Maxim Levitsky

Other info that might help:

I took a look at X and found that it was in normal waiting state
sleeping waiting for input.

Also, I found when 'unstable' mesa would appear to work when I start the
X while 'stable' one is used. It was compiz. When compiz is running
using stable mesa, an game does change the resolution 'usualy' without
hang even if uses unstable mesa.

Best regards,
	Maxim Levitsky

Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Maxim Levitsky <maximlevitsky@gm...>]

On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote:
> On Sat, 06 Mar 2010 18:02:51 +0100
> Stephan Raue <mailinglists@...> wrote:
> 
> > looks this like my problems that i have reported some days ago with 
> > Subject "Problem using an Mesa based App with recent 
> > xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> > 
> > i have still this issue, but i dont know what you need for informations 
> > to fix the issues?
> > 
> > with ati driver i dont have problems, only here with intel driver on my 
> > Thinkpad X200t with intel HDA Graphics card
> > 

I now see that compiz hangs in same way.

Attached are backtrace of the compiz, and backtrace of etracer which did
start full screen but became hung on resolution change.

Best regards,
	Maxim Levitsky

[Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver

[Rafael J. Wysocki <rjw@si...>]

Hi,

For at least two reasons it would be beneficial for some code outisde the
graphics driver(s) to know if the KMS are used.

First, in the non-KMS (ie. UMS) case we probably wouldn't want to call
acpi_video_resume(), because that has a potential to mess up with the GPU
(it actually is known to do that on at least one system).

Second, in the KMS case, we'd be able to skip the kernel VT switch, because
the KMS driver uses its own framebuffer anyway.

So, is there any reasonable way to check that from the outside of the graphics
driver?  It should be general enough to cover the cases when there are two
graphics adapters with different drivers in the system and so forth.

Rafael

[Bug 15276] latest git kernel: general protection fault: 0000 [#1]

[<bugzilla-daemon@bu...>]

http://bugzilla.kernel.org/show_bug.cgi?id=15276





--- Comment #49 from Andreas Wallberg <andreas.wallberg@...>  2010-03-06 21:37:00 ---
For me, the bug never went away, although I noticed that the test case may be
taking a little longer to trigger recently.

As I wrote above, I am using a dual screen arrangement. When the crash happens,
the external screen always goes black. This mostly happens with the internal
laptop LCD too, but every now and then it may instead, over a couple of
seconds, go from whatever was displayed on the screen into being completely
white. At one occasion I also got thin green stripes on the white screen.

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Florian Mickler <florian@mi...>]

On Sat, 06 Mar 2010 18:02:51 +0100
Stephan Raue <mailinglists@...> wrote:

> looks this like my problems that i have reported some days ago with 
> Subject "Problem using an Mesa based App with recent 
> xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?
> 
> i have still this issue, but i dont know what you need for informations 
> to fix the issues?
> 
> with ati driver i dont have problems, only here with intel driver on my 
> Thinkpad X200t with intel HDA Graphics card
> 
> Stephan
> 
> Am 06.03.2010 17:46, schrieb Maxim Levitsky:
> > Here, gdb backtrace while running sauerbraten full screen:
> >
> >
> > #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
> > #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> > #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
> > #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
> >      outCount=0xbfc6a608) at dri2.c:428
> > #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
> >      loaderPrivate=0x93eecb0) at dri2_glx.c:435
> > #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
> > #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
> > #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
> >      min_index=0, max_index=3) at brw_draw.c:340
> > #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
> >      at brw_draw.c:441
> > #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
> > #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
> > #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
> > #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
> > #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
> > #16 0x080abf08 in ?? ()
> > #17 0x080ad3fc in ?? ()
> > #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
> >
> >
> > Best regards,
> > 	Maxim Levitsky
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@...
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >    
> 
> 

with glxgears I can reproduce a hang in _XReply with the same backtrace
up to intel_prepare_render.. i think there are some vblank events
going awol or somewhat like that.. 

i just have to move glxgears from one xrandr head to the next...
(a little bit timing in there, but nonetheless it is easy to trigger)

with the soon-to-be linux-2.6.34-rc1 however, it will now only
hang some 1 or 2 secs then continue to run. 

i'm running on 64bit... (kernel + userland) ... 

hth,
Flo

Re: [git pull] drm request 3

[<tytso@mi...>]

On Sat, Mar 06, 2010 at 11:28:16AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
> 
> > On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> > > Why are people making excuses for bad programming and bad technology?
> > 
> > Is not bad technology is new technology, the API have to change faster ,
> > unless you want wait 2 years until get "stable" .  
> 
> F*ck me, but people are being dense.

Nah, they're just being lazy, selfish b*stards, that's all.  :-(

They want the benefits of lots of testers, without wanting to be
courteous to those testers.

						- Ted

[Bug 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)

[<bugzilla-daemon@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26926





--- Comment #9 from Rafał Miłecki <zajec5@...>  2010-03-06 12:00:15 PST ---
I use drm-linus which contains "fix shr/shl ops".

Thanks a lot for giving registers! It gave nice results :)

# diff -u bad.log ok.log
--- bad.log     2010-03-06 20:54:42.288325112 +0100
+++ ok.log      2010-03-06 20:52:30.060416677 +0100
@@ -52,7 +52,7 @@
 0x7134: 0x02020200
 0x7138: 0x00000000
 0x713C: 0x00000000
-0x7140: 0x000001E6
+0x7140: 0x00000000
 0x7144: 0x00000000
 0x7148: 0x00000000
 0x714C: 0x00000000
@@ -66,5 +66,5 @@
 0x716C: 0x00000000
 rhd_dump: v1.3.0, git branch master, commit d6631a8c
 0x7FF0: 0x00000020
-0x7FF4: 0x00200102
+0x7FF4: 0x00202902
 0x7FF8: 0x00700251

# rhd_dump -w 0x7FF4 0x00202902 1:00.0

It made the trick. Now need just to find out why 0x7FF4 had incorrect value...


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

Re: [git pull] drm request 3

[Linus Torvalds <torvalds@li...>]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:

> On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> > Why are people making excuses for bad programming and bad technology?
> 
> Is not bad technology is new technology, the API have to change faster ,
> unless you want wait 2 years until get "stable" .  

F*ck me, but people are being dense.

With my suggestion, people could change the API _more_, because it 
wouldn't be as painful.

This is not about "change the ABI or not". This is about "since you change 
the ABI, do it _well_, so that it doesn't hurt people as much".

		Linus

Re: [git pull] drm request 3

[Sergio Monteiro Basto <sergio@se...>]

On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote:
> Why are people making excuses for bad programming and bad technology?

Is not bad technology is new technology, the API have to change faster ,
unless you want wait 2 years until get "stable" .  


-- 
Sérgio M. B.

[Bug 26927] Blank LVDS Dell Studio 17

[<bugzilla-daemon@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26927





--- Comment #2 from Damien Mir <dm@...>  2010-03-06 09:56:42 PST ---
(In reply to comment #1)
> Does radeon.new_pll=0 fix it?
> 

No it doesn't, same result.

Note that KMS with mainline 2.6.33 is OK. Seems to occur since recent merges in
linux-next.


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

Re: [PATCH 0/6] HDMI clean & DCE32 support

[Mike Lothian <mike@fi...>]

On 6 March 2010 16:49, Rafał Miłecki <zajec5@...> wrote:
> 2010/3/6 Mike Lothian <mike@...>:
>> 2010/3/6 Rafał Miłecki <zajec5@...>:
>>> This patchset cleans our HDMI code and adds support for DCE32.
>>>
>>> It was tested on:
>>> 1) RV620 with HDMI - no regressions
>>> 2) RV635 with 2 DVI - no regressions
>>> 3) RV730 with HDMI - made it work
>>>
>>> Would be more than great if we still could get this for 2.6.34.
>>>
>>> I could not do this work without help from Christian and Alex, so big thanks
>>> for them :)
>>>
>>> Rafał Miłecki (6):
>>>  drm/radeon/kms: clear HDMI definitions
>>>  drm/radeon/kms: clean assigning HDMI blocks to encoders
>>>  drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs
>>>  drm/radeon/kms: enable audio engine on DCE32
>>>  drm/radeon/kms: remove dead audio/HDMI code
>>>  drm/radeon/kms: improve coding style a little
>>>
>>>  drivers/gpu/drm/radeon/r600_audio.c      |   57 +++-------
>>>  drivers/gpu/drm/radeon/r600_hdmi.c       |  191 +++++++++++++++++++-----------
>>>  drivers/gpu/drm/radeon/r600_reg.h        |   10 +-
>>>  drivers/gpu/drm/radeon/radeon.h          |    3 +-
>>>  drivers/gpu/drm/radeon/radeon_encoders.c |   10 +-
>>>  drivers/gpu/drm/radeon/radeon_mode.h     |    1 +
>>>  drivers/gpu/drm/radeon/rv770.c           |   15 +++
>>>  7 files changed, 166 insertions(+), 121 deletions(-)
>>>
>>>
>>
>> Hi Rafal
>>
>> What kernel do these patches apply cleanly to? Or equally is there a
>> git tree I could pull somewhere?
>
> I do not have own tree, I based patches on drm-linus.
>
> --
> Rafał
>
Apologies I'm not used to patches

I used git apply on the drm-radeon-testing branch with the
--ignore-whitespace option and it compiled cleanly

Not only that I have audio working on my system :-D

Thanks for all your hard work in this area it really is appreciated

If you're ever in Edinburgh I'll happily take you out for a night of
drinking and merriment

Cheers

Mike

Re: [git pull] drm request 3

[Linus Torvalds <torvalds@li...>]

On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote:
> 
> You shouldn't expect, by now, upgrade drm kernel without update libdrm
> or at least recompile libdrm.

Why?

Why shouldn't I expect that? I already outlined exactly _how_ it could be 
done.

Why are people saying that technology has to suck?

> So when you saw a error message "driver nouveau 0.0.n+1 and have 0.0.n"
> is completely right. 

No. It's _not_ right. The code knows what is wrong. Considering it a fatal 
error is _stupid_ and bad technology, when it could have just fixed it.

> Is not a perfect world, but as talked on xorg mailing list, some time
> ago, we do not have resources to test it in all versions.
> Is better focus on just one combination.

This is not about "testing all versions". It's fine to have just one 
combination. But why the hell doesn't it _load_ that one combination 
instead of just dying?

IOW, there is a check for a version. It could - instead of dying - just 
dlopen() the right version instead. 

Why are people making excuses for bad programming and bad technology? 

			Linus

Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Stephan Raue <mailinglists@op...>]

looks this like my problems that i have reported some days ago with 
Subject "Problem using an Mesa based App with recent 
xorg/mesa/xf86-video-intel (loop?)" to Mesa-dev, xorg and intel-gfx list?

i have still this issue, but i dont know what you need for informations 
to fix the issues?

with ati driver i dont have problems, only here with intel driver on my 
Thinkpad X200t with intel HDA Graphics card

Stephan

Am 06.03.2010 17:46, schrieb Maxim Levitsky:
> On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
>    
>> On Sat, 06 Mar 2010 16:40:27 +0200
>> Maxim Levitsky<maximlevitsky@...>  wrote:
>>
>>      
>>> On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote:
>>>        
>>>> On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
>>>>          
>>>>> On Fri, 05 Mar 2010 23:48:48 +0200
>>>>> Maxim Levitsky<maximlevitsky@...>  wrote:
>>>>>
>>>>>            
>>>>>> On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote:
>>>>>>              
>>>>>>> On Fri, 05 Mar 2010 23:18:07 +0200
>>>>>>> Maxim Levitsky<maximlevitsky@...>  wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote:
>>>>>>>>                  
>>>>>>>>> On Fri, 05 Mar 2010 22:42:21 +0200
>>>>>>>>> Maxim Levitsky<maximlevitsky@...>  wrote:
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>>> After quite long period of inactivity, I updated graphical stack on my
>>>>>>>>>> desktop/server.
>>>>>>>>>>
>>>>>>>>>> To say the truth, I did such update about month ago, but found out that
>>>>>>>>>> X refuses flatly to use DRI modules. I assumed that it was my mistake in
>>>>>>>>>> compilation process (although it is automated).
>>>>>>>>>>                      
>>>>>>>>> That generally indicates a build or config problem of some kind.  Did
>>>>>>>>> you ever narrow it down?
>>>>>>>>>                    
>>>>>>>> Because the same compile process works now, I suspect that wasn't build
>>>>>>>> failure.
>>>>>>>>                  
>>>>>>> Well something weird is going on; maybe you didn't build X after Mesa
>>>>>>> or with the right Mesa includes?
>>>>>>>                
>>>>>> I am very sure that this issue isn't relevant now.
>>>>>>
>>>>>> I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in
>>>>>> that order, compiling everything from scratch (doing git clean -dfx in
>>>>>> all directories)
>>>>>>              
>>>>> if you just want a working setup, perhaps you should try using
>>>>> something that got (probably) tested by at least some people:
>>>>>   	http://intellinuxgraphics.org/2009Q4.html
>>>>> cheers,
>>>>> Flo
>>>>>            
>>>> Well, I now have a working setup with mesa
>>>> ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
>>>>
>>>> The problem is that I hoped that once all heavy work in regard to KMS
>>>> was done, there will be no serious regressions in 3D stack, but only bug
>>>> fixes, because it is very hard to track and fix bugs there.
>>>>
>>>> However, once again 3D stack is in bad shape, and this is not good.
>>>>          
>>>
>>> More testing shows the following behaviour:
>>>
>>>
>>>
>>> Full screen mode is completely busted. As soon as any 3D application
>>> switches to full screen mode, even without changing the resolution, it
>>> hangs (note that I didn't see GPU hangs due to that)
>>>
>>> Compiz is broken (its also a full screen app...). As soon as it starts,
>>> it draws few windows, and then stalls.
>>>
>>> In window mode all applications do work.
>>>
>>>
>>> Now I guess this is worth a bugzilla entry.
>>> (If this isn't there yet...)
>>>        
>> I'm not seeing this on GM45.  I just installed a totally fresh stack on
>> a new F12 installation and compiz and games work well.  But please file
>> a bug and include everything needed (see intellinuxgraphics.org for the
>> list); hope we can find the issue.
>>      
>
> Here, gdb backtrace while running sauerbraten full screen:
>
>
> #2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
> #3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
> #4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
> #5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2,
>      outCount=0xbfc6a608) at dri2.c:428
> #6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608,
>      loaderPrivate=0x93eecb0) at dri2_glx.c:435
> #7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
> #8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
> #9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001',
>      min_index=0, max_index=3) at brw_draw.c:340
> #10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
>      at brw_draw.c:441
> #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
> #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
> #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
> #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
> #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
> #16 0x080abf08 in ?? ()
> #17 0x080ad3fc in ?? ()
> #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20<_dl_fini>,
>
>
> Best regards,
> 	Maxim Levitsky
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@...
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>    


-- 
               ### OpenELEC.tv ###
The free and open Mediacenter Distribution 4 you
              http://www.openelec.tv

[Bug 26927] Blank LVDS Dell Studio 17

[<bugzilla-daemon@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26927





--- Comment #1 from Alex Deucher <agd5f@...>  2010-03-06 09:26:48 PST ---
Does radeon.new_pll=0 fix it?


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

Re: [git pull] drm request 3

[<Valdis.Kletnieks@vt...>]

On Fri, 05 Mar 2010 18:04:34 +0200, Daniel Stone said:

> So you're saying that there's no way to develop any reasonable body of
> code for the Linux kernel without committing to keeping your ABI
> absolutely rock-solid stable for eternity, no exceptions, ever? Cool,
> that worked really well for Xlib.

Amen to that.  I can remember the X10.4->X11 conversion in 1987. And a heck of
a lot of source-level stability since then (even with the libX11 getting redone
with libxcb under it. 23 years and still going strong is one hell of a good run
for an ABI.

Re: [PATCH 0/6] HDMI clean & DCE32 support

[Mike Lothian <mike@fi...>]

2010/3/6 Rafał Miłecki <zajec5@...>:
> This patchset cleans our HDMI code and adds support for DCE32.
>
> It was tested on:
> 1) RV620 with HDMI - no regressions
> 2) RV635 with 2 DVI - no regressions
> 3) RV730 with HDMI - made it work
>
> Would be more than great if we still could get this for 2.6.34.
>
> I could not do this work without help from Christian and Alex, so big thanks
> for them :)
>
> Rafał Miłecki (6):
>  drm/radeon/kms: clear HDMI definitions
>  drm/radeon/kms: clean assigning HDMI blocks to encoders
>  drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs
>  drm/radeon/kms: enable audio engine on DCE32
>  drm/radeon/kms: remove dead audio/HDMI code
>  drm/radeon/kms: improve coding style a little
>
>  drivers/gpu/drm/radeon/r600_audio.c      |   57 +++-------
>  drivers/gpu/drm/radeon/r600_hdmi.c       |  191 +++++++++++++++++++-----------
>  drivers/gpu/drm/radeon/r600_reg.h        |   10 +-
>  drivers/gpu/drm/radeon/radeon.h          |    3 +-
>  drivers/gpu/drm/radeon/radeon_encoders.c |   10 +-
>  drivers/gpu/drm/radeon/radeon_mode.h     |    1 +
>  drivers/gpu/drm/radeon/rv770.c           |   15 +++
>  7 files changed, 166 insertions(+), 121 deletions(-)
>
>

Hi Rafal

What kernel do these patches apply cleanly to? Or equally is there a
git tree I could pull somewhere?

Cheers

Mike

Re: [PATCH 0/6] HDMI clean & DCE32 support

[Rafał Miłecki <zajec5@gm...>]

2010/3/6 Mike Lothian <mike@...>:
> 2010/3/6 Rafał Miłecki <zajec5@...>:
>> This patchset cleans our HDMI code and adds support for DCE32.
>>
>> It was tested on:
>> 1) RV620 with HDMI - no regressions
>> 2) RV635 with 2 DVI - no regressions
>> 3) RV730 with HDMI - made it work
>>
>> Would be more than great if we still could get this for 2.6.34.
>>
>> I could not do this work without help from Christian and Alex, so big thanks
>> for them :)
>>
>> Rafał Miłecki (6):
>>  drm/radeon/kms: clear HDMI definitions
>>  drm/radeon/kms: clean assigning HDMI blocks to encoders
>>  drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs
>>  drm/radeon/kms: enable audio engine on DCE32
>>  drm/radeon/kms: remove dead audio/HDMI code
>>  drm/radeon/kms: improve coding style a little
>>
>>  drivers/gpu/drm/radeon/r600_audio.c      |   57 +++-------
>>  drivers/gpu/drm/radeon/r600_hdmi.c       |  191 +++++++++++++++++++-----------
>>  drivers/gpu/drm/radeon/r600_reg.h        |   10 +-
>>  drivers/gpu/drm/radeon/radeon.h          |    3 +-
>>  drivers/gpu/drm/radeon/radeon_encoders.c |   10 +-
>>  drivers/gpu/drm/radeon/radeon_mode.h     |    1 +
>>  drivers/gpu/drm/radeon/rv770.c           |   15 +++
>>  7 files changed, 166 insertions(+), 121 deletions(-)
>>
>>
>
> Hi Rafal
>
> What kernel do these patches apply cleanly to? Or equally is there a
> git tree I could pull somewhere?

I do not have own tree, I based patches on drm-linus.

-- 
Rafał

Re: [PATCH 2/6] drm/radeon/kms: clean assigning HDMI blocks to encoders

[Rafał Miłecki <zajec5@gm...>]

W dniu 6 marca 2010 17:26 użytkownik Christian König
<deathsimple@...> napisał:
> Am Samstag, den 06.03.2010, 14:03 +0100 schrieb Rafał Miłecki:
>> +     struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>>       int base_rate = 48000;
>>
>> +     if (!dig) {
>> +             dev_err(rdev->dev, "Setting audio clock on non-dig encoder\n");
>> +             return;
>> +     }
>> +
> ...
>> -     switch (r600_audio_tmds_index(encoder)) {
>> +     switch (dig->dig_encoder) {
>>       case 0:
>>               WREG32(R600_AUDIO_PLL1_MUL, base_rate*50);
>>               WREG32(R600_AUDIO_PLL1_DIV, clock*100);
> ....
>>               WREG32(R600_AUDIO_PLL2_DIV, clock*100);
>>               WREG32(R600_AUDIO_CLK_SRCSEL, 1);
>>               break;
>> +     default:
>> +             dev_err(rdev->dev, "Unsupported DIG on encoder 0x%02X\n",
>> +                       radeon_encoder->encoder_id);
>> +             return;
> I know that I made the suggestion to code it like this, but now I'm
> thinking that we should make it depend on the hdmi_offset instead of the
> dig_encoder number. First I'm not sure that radeon_encoder->enc_priv
> will always point to a radeon_encoder_atom_dig structure, and second I
> think the possibility of rerouting the signals on pre DCE3 makes this
> decision depend on the wrong index.

Not sure about dig pointer... I think it should be always available.
But indeed it can be wrong for pre-DCE3. Thanks for pointing.

-- 
Rafał

Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again

[Maxim Levitsky <maximlevitsky@gm...>]

On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote:
> On Sat, 06 Mar 2010 16:40:27 +0200
> Maxim Levitsky <maximlevitsky@...> wrote:
> 
> > On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: 
> > > On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote:
> > > > On Fri, 05 Mar 2010 23:48:48 +0200
> > > > Maxim Levitsky <maximlevitsky@...> wrote:
> > > > 
> > > > > On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote:
> > > > > > On Fri, 05 Mar 2010 23:18:07 +0200
> > > > > > Maxim Levitsky <maximlevitsky@...> wrote:
> > > > > > 
> > > > > > > On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote:
> > > > > > > > On Fri, 05 Mar 2010 22:42:21 +0200
> > > > > > > > Maxim Levitsky <maximlevitsky@...> wrote:
> > > > > > > > 
> > > > > > > > > After quite long period of inactivity, I updated graphical stack on my
> > > > > > > > > desktop/server.
> > > > > > > > > 
> > > > > > > > > To say the truth, I did such update about month ago, but found out that
> > > > > > > > > X refuses flatly to use DRI modules. I assumed that it was my mistake in
> > > > > > > > > compilation process (although it is automated).
> > > > > > > > 
> > > > > > > > That generally indicates a build or config problem of some kind.  Did
> > > > > > > > you ever narrow it down?
> > > > > > > Because the same compile process works now, I suspect that wasn't build
> > > > > > > failure.
> > > > > > 
> > > > > > Well something weird is going on; maybe you didn't build X after Mesa
> > > > > > or with the right Mesa includes?
> > > > > I am very sure that this issue isn't relevant now.
> > > > > 
> > > > > I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in
> > > > > that order, compiling everything from scratch (doing git clean -dfx in
> > > > > all directories)
> > > > 
> > > > if you just want a working setup, perhaps you should try using
> > > > something that got (probably) tested by at least some people:
> > > >  	http://intellinuxgraphics.org/2009Q4.html
> > > > cheers,
> > > > Flo
> > > 
> > > Well, I now have a working setup with mesa 
> > > ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5
> > > 
> > > The problem is that I hoped that once all heavy work in regard to KMS
> > > was done, there will be no serious regressions in 3D stack, but only bug
> > > fixes, because it is very hard to track and fix bugs there.
> > > 
> > > However, once again 3D stack is in bad shape, and this is not good.
> > 
> > 
> > More testing shows the following behaviour:
> > 
> > 
> > 
> > Full screen mode is completely busted. As soon as any 3D application
> > switches to full screen mode, even without changing the resolution, it
> > hangs (note that I didn't see GPU hangs due to that)
> > 
> > Compiz is broken (its also a full screen app...). As soon as it starts,
> > it draws few windows, and then stalls.
> > 
> > In window mode all applications do work.
> > 
> > 
> > Now I guess this is worth a bugzilla entry.
> > (If this isn't there yet...)
> 
> I'm not seeing this on GM45.  I just installed a totally fresh stack on
> a new F12 installation and compiz and games work well.  But please file
> a bug and include everything needed (see intellinuxgraphics.org for the
> list); hope we can find the issue.


Here, gdb backtrace while running sauerbraten full screen:


#2  0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1
#3  0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#4  0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454
#5  0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, 
    outCount=0xbfc6a608) at dri2.c:428
#6  0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608, 
    loaderPrivate=0x93eecb0) at dri2_glx.c:435
#7  0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253
#8  0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395
#9  0xb657a423 in brw_try_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', 
    min_index=0, max_index=3) at brw_draw.c:340
#10 brw_draw_prims (ctx=<value optimized out>, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3)
    at brw_draw.c:441
#11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384
#12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfffffdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872
#13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906
#14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283
#15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007
#16 0x080abf08 in ?? ()
#17 0x080ad3fc in ?? ()
#18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20 <_dl_fini>, 


Best regards,
	Maxim Levitsky

Re: [PATCH 2/6] drm/radeon/kms: clean assigning HDMI blocks to encoders

[Christian König <deathsimple@vo...>]

Am Samstag, den 06.03.2010, 14:03 +0100 schrieb Rafał Miłecki:
> +	struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv;
>  	int base_rate = 48000;
>  
> +	if (!dig) {
> +		dev_err(rdev->dev, "Setting audio clock on non-dig encoder\n");
> +		return;
> +	}
> +
... 
> -	switch (r600_audio_tmds_index(encoder)) {
> +	switch (dig->dig_encoder) {
>  	case 0:
>  		WREG32(R600_AUDIO_PLL1_MUL, base_rate*50);
>  		WREG32(R600_AUDIO_PLL1_DIV, clock*100);
....
>  		WREG32(R600_AUDIO_PLL2_DIV, clock*100);
>  		WREG32(R600_AUDIO_CLK_SRCSEL, 1);
>  		break;
> +	default:
> +		dev_err(rdev->dev, "Unsupported DIG on encoder 0x%02X\n",
> +			  radeon_encoder->encoder_id);
> +		return;
I know that I made the suggestion to code it like this, but now I'm
thinking that we should make it depend on the hdmi_offset instead of the
dig_encoder number. First I'm not sure that radeon_encoder->enc_priv
will always point to a radeon_encoder_atom_dig structure, and second I
think the possibility of rerouting the signals on pre DCE3 makes this
decision depend on the wrong index.

Currently checking this out on my hardware, so stay tuned for an update.

Regards,
Christian.

[Bug 26927] New: Blank LVDS Dell Studio 17

[<bugzilla-daemon@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=26927

           Summary: Blank LVDS Dell Studio 17
           Product: DRI
           Version: XOrg CVS
          Platform: x86-64 (AMD64)
        OS/Version: Linux (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: DRM/Radeon
        AssignedTo: dri-devel@...
        ReportedBy: dm@...


When using linux-next-20100305 with drm/radeon/kms, the LVDS panel of my laptop
(Dell Studio 17) gets blank, and occasionally displays some brief artifacts
when the KDM login screen supposed to pop up.

Maybe it needs some quirks (as Alex Daucher did for Dell Studio 15) ?


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