Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Alan Cox]

> > On both cases, the requirement is to pass a framebuffer between two 
> > entities, 
> > and not a video stream.

It may not even be a framebuffer. In many cases you'll pass a framebuffer
or some memory target (in DRI think probably a GEM handle), in fact in
theory you can do much of this now.

> > use a buffer that were filled already by the camera. Also, the V4L2 camera
> > driver can't re-use such framebuffer before being sure that both consumers 
> > has already stopped using it.

You also potentially need fences which complicates the interface
somewhat.

> The use case above isn't even possible without copying. At least, I don't see 
> a
> way, unless the GPU buffer is non-destructive. In that case you can give the
> frame to the GPU, and when the GPU is finished you can give it to the encoder.
> I suspect that might become quite complex though.

It's actually no different to giving a buffer to the GPU some of the time
and the CPU other bits. In those cases you often need to ensure private
ownership each side and do fencing/cache flushing as needed.

> Note that many video receivers cannot stall. You can't tell them to wait until
> the last buffer finished processing. This is different from some/most? 
> sensors.

A lot of video receivers also keep the bits away from the CPU as part of
the general DRM delusion TV operators work under. That means you've got
an object that has a handle, has operations (alpha, fade, scale, etc) but
you can never touch the bits. In the TV/Video world not unsurprisingly
that is often seen as the 'primary' frame buffer as well. You've got a
set of mappable framebuffers the CPU can touch plus other video sources
that can be mixed and placed but the CPU can only touch the mappable
objects that form part of the picture.

Alan

[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Tom Stellard  2011-05-15 22:01:41 
PDT ---
Created an attachment (id=46753)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46753
 Review: https://bugs.freedesktop.org/review?bug=36753=46753

Verbose patch

The patch will give me some extra debug info.  Can you apply it and post the
output of RADEON_DEBUG=fp.

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

Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Rob Clark]

On Sun, May 15, 2011 at 4:27 PM, Alan Cox  wrote:
>> > On both cases, the requirement is to pass a framebuffer between two 
>> > entities,
>> > and not a video stream.
>
> It may not even be a framebuffer. In many cases you'll pass a framebuffer
> or some memory target (in DRI think probably a GEM handle), in fact in
> theory you can do much of this now.
>
>> > use a buffer that were filled already by the camera. Also, the V4L2 camera
>> > driver can't re-use such framebuffer before being sure that both consumers
>> > has already stopped using it.
>
> You also potentially need fences which complicates the interface
> somewhat.

Presumable this is going through something like DRI2, so the client
application, which is what is interacting w/ V4L2 interface for camera
and perhaps video encoder, would call something that turns into a
ScheduleSwap() call on xserver side, returning a frame count to wait
for, and then at some point later ScheduleWaitMSC() to wait for that
frame count to know the GPU is done with the buffer.  The fences would
be buried somewhere within DRM (kernel) and xserver driver (userspace)
to keep the client app blocked until GPU is done.

You probably don't want the V4L2 devices to be too deeply connected to
how the GPU does synchronization, or otherwise V4L2 would need to
support each different DRM+xserver driver and how it implements buffer
synchronization with the GPU..

BR,
-R

>> The use case above isn't even possible without copying. At least, I don't 
>> see a
>> way, unless the GPU buffer is non-destructive. In that case you can give the
>> frame to the GPU, and when the GPU is finished you can give it to the 
>> encoder.
>> I suspect that might become quite complex though.
>
> It's actually no different to giving a buffer to the GPU some of the time
> and the CPU other bits. In those cases you often need to ensure private
> ownership each side and do fencing/cache flushing as needed.
>
>> Note that many video receivers cannot stall. You can't tell them to wait 
>> until
>> the last buffer finished processing. This is different from some/most? 
>> sensors.
>
> A lot of video receivers also keep the bits away from the CPU as part of
> the general DRM delusion TV operators work under. That means you've got
> an object that has a handle, has operations (alpha, fade, scale, etc) but
> you can never touch the bits. In the TV/Video world not unsurprisingly
> that is often seen as the 'primary' frame buffer as well. You've got a
> set of mappable framebuffers the CPU can touch plus other video sources
> that can be mixed and placed but the CPU can only touch the mappable
> objects that form part of the picture.
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-dae...@freedesktop.org]

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

--- Comment #14 from Marek Ol??k  2011-05-15 18:13:03 PDT 
---
Created an attachment (id=46752)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46752
 Review: https://bugs.freedesktop.org/review?bug=35998=46752

little experiment

(In reply to comment #13)
> After more thorough testing, it seems that r300 driver is not able to 
> correctly
> create surfaces of certain dimensions; random vram content is shown instead.

Not true. The r300 driver gets it right for all the other GPUs, it's just rs6xx
that is broken.

Please try the attached patch.

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

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

Hey,

* Michael Chang -- Friday 13 May 2011:
> But there's more questions in my mind, made me feel not
> able to proceed any further.. :(

No problem. The reason for inconsistencies in my reports is
simply that I've realized some properties only later. So here's
a new error description, based on ddb503b42960, which is current
HEAD.


On this "Acer Travelmate 5735Z-452G32Mnss" the following happens
since after 2.6.37-rc8, with acpi_osi=Linux:

- the backlight goes dark as soon as KMS takes over early in the
  boot process (the screen contents aren't corrupted, though, and
  under appropriate lighting conditions I can even see the
  (very dark) uncorrupted contents.)

- when I press the "backlight darker" key, the backlight is turned
  on. (No other key does that AFAICS, including "display toggle"
  and "backlight brighter.)

Everything works correctly after that, including backlight adjustment,
BUT:

 - when I close the lid and open it again, the backlight stays black
   again, just like before. Backlight adjustment turns it on, and
   now even the "brighter" key does it sometimes, but not always.)



> 1. is_backlight_combination_mode() really returns 0x4 ..?

[PULL] drm-intel-next

[Keith Packard]

vers/gpu/drm/i915/intel_drv.h|   19 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c |   38 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |   35 +-
 drivers/gpu/drm/i915/intel_tv.c |   13 +-
 20 files changed, 2124 insertions(+), 1181 deletions(-)


-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110515/d0ffe275/attachment.pgp>

[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

[bugzilla-dae...@freedesktop.org]

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

--- Comment #9 from Brian Paterni  2011-05-15 14:13:49 
PDT ---
Created an attachment (id=46749)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46749)
css kernel backtraces

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

[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

[bugzilla-dae...@freedesktop.org]

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

--- Comment #8 from Brian Paterni  2011-05-15 14:10:45 
PDT ---
Update: CS: Source now successfully boots up to the menu! However I'm unsure
whether this is due to fix in mesa, wine, or libc6.

Though now if I attempt to start and load a game from the menu, everything
appears to go though smoothly until the last few bits are initialized. From
there I'm put into a loop of GPU lockups and GPU resets. Therefore this bug may
be related to #36421 now. The game still renders the match welcome screen
throughout these GPU lockup/reset cycles though, and I am able to eventually
switch to different workspace to kill the cstrike process.

Additionally, the in game stress test renders reasonably well until the camera
begins to enter the room with the transparent player model with flames behind
it (forgive me if I'm not using the correct terminology). At this point (before
the flames "turn on") the stress test freezes and goes into the gpu reset loop
described above.

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

i915/kms/backlight-combo mode problem

[Takashi Iwai]

At Tue, 10 May 2011 13:08:23 +0200,
Melchior FRANZ wrote:
> 
> * Michael Chang -- Tuesday 10 May 2011:
> > Could you please try this patch and get the log ? We wonder why
> > is_backlight_combination_mode () returns false.
> 
> This information was already buried in the bugzilla thread:
> 
>   https://bugzilla.kernel.org/show_bug.cgi?id=31522
>   "It turned out that on this machine INTEL_INFO(dev)->gen equals 4,
>   and is_backlight_combination_mode() returns 0x4000."
> 
> 
> But to say it again in your words:   :-)
> 
>   [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824  
> (0x4000)
> 
> 6x during boot-up, and several times later when changing the backlight
> brightness.
> 
> 
> This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now
> I have a little shocker for you (and me): because this was a
> vanilla kernel (apart from these debug messages), the screen went
> black again, like I knew it. But pressing the "brightness down"
> key turns the backlight on! I can't believe that I haven't tested
> that. I guess I've only tried "brightness up" and "display toggle".
> Those don't turn backlight on. Or maybe somethine else relevant
> meanwhile changed in the i915 drivers. (I've regularly been
> updating to HEAD.)  
> 
> So, the problem was just the initial state all the time?

Looks so, indeed.  Now, the question is what's the real cause.

IIRC, you reported that the backlight gets normal when you revert my
commit in 2.6.38.x.  So, this was regarded as a regression at first.
But, one question remains: whether the backlight level control worked
with the reverted kernel?
Judging from the attempts so far, it looks like that only LBPC can
adjust the level on your machine.  If it's true, 2.6.38.0 shouldn't be
able to adjust the level.  If you can still change the level without
LBPC, the former analysis was incorrect.

Also, with the latest 2.6.38.x, you found that the backlight gets back
when you adjust the level down.  Another question now is what happens
if you again turn it up to the max level.  Is the backlight still on?

If the backlight is kept on even with the max level, it implies that
the problem is only the initial value; once when set correctly, it'll
work fine after that.  OTOH, if the backlight gets off again at max,
it means that the max value (LBPC 0xfe) is a sort of out-of-range.
Then LBPC calculation in the driver has to be modified.


thanks,

Takashi

[Bug 16687] Desktop corruption when enabling Desktop Effects

[bugzilla-dae...@freedesktop.org]

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

--- Comment #12 from almos  2011-05-15 10:54:25 PDT ---
Is this problem still around? According to comments #6 and #9 it is fixed in
the currently preferred codepath (KMS/DRI2/EXA).

> Sadly, Mozilla's opinion is that security comes from paying shitloads of
> money to VeriSign.  Hopefully they'll see the sense in publishing the
> CACert CA, and we'll have a CACert certificate, which will validate.
This is a known design flaw of SSL. See
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
for more information.

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

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-dae...@freedesktop.org]

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

--- Comment #13 from Milan Plzik  2011-05-15 10:34:56 PDT 
---
After more thorough testing, it seems that r300 driver is not able to correctly
create surfaces of certain dimensions; random vram content is shown instead.
Also, it doesn't seem to change, despite of application changing contents of
its window. I tried some more changes in the alignment table (like multiplying
related alignments by two), but it had only negative effect.

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

[Bug 31782] nouveau: lockdep spew

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=31782


Rafael J. Wysocki  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 37227] New: z-buffer errors in doom3 outside the airlock

[bugzilla-dae...@freedesktop.org]

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

   Summary: z-buffer errors in doom3 outside the airlock
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: aaalmosss at gmail.com


Created an attachment (id=46742)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46742)
z-error.png

When the outer doors of the airlocks are open, the shadows inside the building
are drawn on top of everything (except the HUD). Disabling shadows in the
advanced settings makes them disappear. While being indoors, everything is
rendered correctly AFAICT.

With r300c every shadow was drawn on top of everything, but those covered the
HUD as well. This might be a similar problem.

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

[Bug 37225] New: Penumbra: Motion blur not working correctly

[bugzilla-dae...@freedesktop.org]

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

   Summary: Penumbra: Motion blur not working correctly
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://www.penumbragame.com/
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: sa at whiz.se


Created an attachment (id=46739)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46739)
Motion blur bug

The motion blur effect in the Penumbra games isn't rendering correctly.

Probably r600g specific since it's working with llvmpipe.

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-51095f7
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

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

[Bug 31782] nouveau: lockdep spew

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=31782


Johannes Berg  changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||CODE_FIX




--- Comment #10 from Johannes Berg   2011-05-15 
06:24:28 ---
Sorry, I must've missed your email earlier -- I'm now on 2.6.39-rc7 and it
doesn't seem to have this issue any more.

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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 35095] [r300g] HiZ broken in WoW

[bugzilla-dae...@freedesktop.org]

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

--- Comment #10 from Chris Rankin  2011-05-15 
05:06:36 PDT ---
(In reply to comment #9)
> Could you test the latest Mesa master branch? There are some new HiZ fixes.

At best, those HiZ fixes didn't help. But I suspect the corrupt area on the
login screen may actually be larger now.

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

[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Jure Repinc  2011-05-15 04:01:26 PDT 
---
Created an attachment (id=46736)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46736)
Xorg.0.log

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

[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #2 from Jure Repinc  2011-05-15 04:00:39 PDT 
---
Created an attachment (id=46735)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46735)
lspci

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

[Bug 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Jure Repinc  2011-05-15 04:00:01 PDT 
---
Created an attachment (id=46734)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46734)
dmesg

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

[Bug 37220] New: RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-dae...@freedesktop.org]

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

   Summary: RS482: Screen starts flashing after screensaver with
KDE KWin desktop effects enabled
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: jlp.bugs at gmail.com


After a very long time I have got my old laptop with integrated ATI Radeon
Xpress 200M. I remeber running it with desktop effects enabled and classic mesa
r300 driver just fine. Well now wit Gallium I have this annoying problem:

I have the screensaver set to Solar Winds from KDE's kdeartwork/screensaver
package. As usually I left the computer alone and when I came back and moved
the mouse screensaver turned off. But what started happening was that the
screen was flashing. Parts of it (rectangular) were becoming black or werw
coming from black to normal. Thoose parts are the parts that the mouse was
traveling over. Just as if the damaged areas which needed redrawing.

To make this go away I had to turn off the desktop effects (using
Alt+Shift+F12) and then turn them back on (with same keybiard shortcut).

The flashing effect is especially visible if I have the KDE's Screen Saver
control center module open and test OpenGL screensavers from there.

Reproducable: always

Software in use:
* mesa: git-bd5b7a6
* kde: 4.6.3
* xorg server: 1.10.1.901
* linux kernel: 2.6.39-rc7

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

[Bug 37193] Crash while switching between OpenGL window and other window

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from Mathias Brodala  2011-05-15 03:15:03 
PDT ---
(In reply to comment #2)
> Can you attach your xorg log and dmesg output?

Here they are. I tried to make sure that everything is written to disk by
running an endless loop calling "sync" but to no avail. The files contain no
traces at all from a crash or the like.

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

[Bug 37193] Crash while switching between OpenGL window and other window

[bugzilla-dae...@freedesktop.org]

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

--- Comment #4 from Mathias Brodala  2011-05-15 03:12:52 
PDT ---
Created an attachment (id=46733)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46733)
dmesg log file

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

[Bug 37193] Crash while switching between OpenGL window and other window

[bugzilla-dae...@freedesktop.org]

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

--- Comment #3 from Mathias Brodala  2011-05-15 03:12:32 
PDT ---
Created an attachment (id=46732)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46732)
X.org log file

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

[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g

[bugzilla-dae...@freedesktop.org]

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

almos  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #3 from almos  2011-05-15 02:49:49 PDT ---
Unfortunately, commit 51095f74cf92d3cada7366ce898ade7693570b48 doesn't fix the
missing triangles in ut2004.

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

2.6.39-rc7-git7: Reported regressions 2.6.37 -> 2.6.38

[Rafael J. Wysocki]

[NOTE:
 This most likely is the last summary report of post-2.6.37 regressions
 introduced during the 2.6.38 development cycle.  Please let us know what
 the current status of those bugs is, if possible, and thanks for all of
 the reports, updates and fixes.]

This message contains a list of some post-2.6.37 regressions introduced before
2.6.38, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved post-2.6.37 regressions, please let us know
either and we'll add them to the list.  Also, please let us know if any
of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.


Listed regressions statistics:

  Date  Total  Pending  Unresolved
  
  2011-05-15  107   23  20
  2011-04-30  105   29  28
  2011-04-17   98   28  28
  2011-03-27   88   26  26
  2011-03-06   70   27  26
  2011-02-21   51   18  17
  2011-02-12   39   20  18
  2011-02-03   19   11   7


Unresolved regressions
--

Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34992
Subject : Regression with ath5k, cannot find any wireless network
Submitter   : Joshua Covington 
Date: 2011-05-12 11:24 (3 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33982
Subject : ath9k: regulatory: strange tx power limits
Submitter   : Richard Sch?tz 
Date: 2011-04-26 18:37 (19 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33882
Subject : rt2800pci bad performance in 2.6.38
Submitter   : Ricardo Gra?a 
Date: 2011-04-23 14:35 (22 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33852
Subject : Regression of AR2413 802.11bg in 2.6.38.4
Submitter   : Boris Popov 
Date: 2011-04-23 12:12 (22 days old)
First-Bad-Commit: 
http://git.kernel.org/linus/42c025f3de9042d9c9abd9a6f6205d1a0f4bcadf


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33662
Subject : System hangs during X startup (kwin compositing?)
Submitter   : Luke-Jr 
Date: 2011-04-19 04:26 (26 days old)
First-Bad-Commit: 
http://git.kernel.org/linus/e8616b6ced6137085e6657cc63bc2fe3900b8616


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=32862
Subject : acer_wmi partially crashes ACPI/EC (Aspire 8930G)
Submitter   : Hector Martin 
Date: 2011-04-07 17:44 (38 days old)
Handled-By  : Lee, Chun-Yi 


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=32522
Subject : drm:i915_hangcheck_ring_idle after suspend/resume cycle
Submitter   :  
Date: 2011-04-02 18:40 (43 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=32202
Subject : 2.6.38 hangs on boot until key is pressed
Submitter   : Tvrtko Ursulin 
Date: 2011-03-27 19:18 (49 days old)
Message-ID  : <1301253485.2500.2.camel at deuteros>
References  : http://marc.info/?l=linux-kernel=13012546558=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=31922
Subject : ath5k: Decreased throughput in IBSS or 802.11n mode
Submitter   : Jeff Cook 
Date: 2011-03-26 20:06 (50 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=31782
Subject : nouveau: lockdep spew
Submitter   : Johannes Berg 
Date: 2011-03-24 09:51 (52 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=31572
Subject : BUG in vb_alloc() - firewire crash at boot
Submitter   : Pavel Kysilka 
Date: 2011-03-21 12:40 (55 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=31402
Subject : Diminished brightness at startup
Submitter   : Guilherme Salazar 
Date: 2011-03-18 16:29 (58 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=31322
Subject : 2.6.38-rc echo 3 > /proc/sys/vm/drop_caches repairs mplayer 
distortions
Submitter   : Hans de Bruin 
Date: 2011-03-14 21:34 (62 days old)
Message-ID  : <4D7E89E7.3080505 at xmsnet.nl>
References  : http://marc.info/?l=linux-kernel=130014181919827=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=31012
Subject : WARNING: Perf: bad frame pointer = (null), 2.6.38-rc8
Submitter   : Chuck Ebbert 
Date: 2011-03-12 19:08 (64 days old)
Message-ID  : <20110312140851.52420149 at katamari>
References  : http://marc.info/?l=linux-kernel=129995721014931=2


Bug-Entry   : 

2.6.39-rc7-git7: Reported regressions from 2.6.38

[Rafael J. Wysocki]

This message contains a list of some regressions from 2.6.38,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.

If you know of any other unresolved regressions from 2.6.38, please let us
know either and we'll add them to the list.  Also, please let us know
if any of the entries below are invalid.

Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.


Listed regressions statistics:

  Date  Total  Pending  Unresolved
  
  2011-05-15   50   12  11
  2011-04-30   38   17  16
  2011-04-17   17   11  10


Unresolved regressions
--

Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=35062
Subject : Suspend to ram stopped working after commit of " intel-iommu: 
Unlink domain from iommu "
Submitter   :  
Date: 2011-05-14 11:08 (1 days old)
First-Bad-Commit: 
http://git.kernel.org/linus/a97590e56d0d58e1dd262353f7cbd84e81d8e600


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34952
Subject : 2.6.39-rc6: SATA hangs for a few seconds during boot
Submitter   : Tino Keitel 
Date: 2011-05-09 20:48 (6 days old)
Message-ID  : <20110509204801.GA2258 at x61.home>
References  : http://marc.info/?l=linux-kernel=130497409509438=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34942
Subject : [Bug] Kdump does not work when panic triggered due to MCE
Submitter   : K.Prasad 
Date: 2011-05-06 16:54 (9 days old)
Message-ID  : <20110506165412.GB2719 at in.ibm.com>
References  : http://marc.info/?l=linux-kernel=130470087226270=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34662
Subject : Warning at block/genhd.c:1556 disk_clear_events
Submitter   : Meelis Roos 
Date: 2011-05-02 9:59 (13 days old)
Message-ID  : 
References  : http://marc.info/?l=linux-kernel=130433037002610=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34492
Subject : [2.6.39-rc4, x86_32] Stall at default_idle()
Submitter   : Tetsuo Handa 
Date: 2011-04-27 4:49 (18 days old)
Message-ID  : <201104270449.p3R4n54n023453 at www262.sakura.ne.jp>
References  : http://marc.info/?l=linux-kernel=130387977425687=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34202
Subject : MCEUSB remotes don't work with USB 3.0 ports
Submitter   : Aaron Barany 
Date: 2011-05-01 23:48 (14 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=34002
Subject : [REGRESSION] [2.6.39-rc3] Wrong resolution in framebuffer and 
X Window
Submitter   : Maciej Rutecki 
Date: 2011-04-17 16:04 (28 days old)
Message-ID  : <201104171804.04664.maciej.rutecki at gmail.com>
References  : http://marc.info/?l=linux-fbdev=130305625114863=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33842
Subject : NULL pointer dereference in ip_fragment
Submitter   : Tomas Carnecky 
Date: 2011-04-23 07:51 (22 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33792
Subject : lockdep trace when unplugging usb audio (.39rc4)
Submitter   : Dave Jones 
Date: 2011-04-19 18:07 (26 days old)
Message-ID  : <20110419180745.GA438 at redhat.com>
References  : http://marc.info/?l=linux-kernel=130323648920431=2


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33272
Subject : drm related hard-hang
Submitter   : Peter Teoh 
Date: 2011-04-14 01:29 (31 days old)


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33242
Subject : Lockdep splat in autofs with 2.6.39-rc2
Submitter   : Nick Bowler 
Date: 2011-04-07 19:44 (38 days old)
Message-ID  : <20110407194403.GA29404 at elliptictech.com>
References  : http://marc.info/?l=linux-kernel=130220545614682=2


Regressions with patches


Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=33802
Subject : list_del corruption in sd driver since 2.6.39-rc4
Submitter   : Christian Casteyde 
Date: 2011-04-21 21:10 (24 days old)
Handled-By  : James Bottomley 
Patch   : http://marc.info/?l=linux-kernel=130271409412095


For details, please visit the bug entries and follow the links given in
references.

As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.38,
unresolved as well as resolved, at:

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

Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.

[Bug 31782] nouveau: lockdep spew

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=31782


Johannes Berg johan...@sipsolutions.net changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||CODE_FIX




--- Comment #10 from Johannes Berg johan...@sipsolutions.net  2011-05-15 
06:24:28 ---
Sorry, I must've missed your email earlier -- I'm now on 2.6.39-rc7 and it
doesn't seem to have this issue any more.

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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 31782] nouveau: lockdep spew

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=31782


Rafael J. Wysocki r...@sisk.pl changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED




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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36609] 45920d2ecb38b14fdda5253fecce996570c22863 breaks sauerbraten on r300g

[bugzilla-daemon]

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

almos aaalmo...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #3 from almos aaalmo...@gmail.com 2011-05-15 02:49:49 PDT ---
Unfortunately, commit 51095f74cf92d3cada7366ce898ade7693570b48 doesn't fix the
missing triangles in ut2004.

-- 
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: i915/kms/backlight-combo mode problem

[Takashi Iwai]

At Tue, 10 May 2011 13:08:23 +0200,
Melchior FRANZ wrote:
 
 * Michael Chang -- Tuesday 10 May 2011:
  Could you please try this patch and get the log ? We wonder why
  is_backlight_combination_mode () returns false.
 
 This information was already buried in the bugzilla thread:
 
   https://bugzilla.kernel.org/show_bug.cgi?id=31522
   It turned out that on this machine INTEL_INFO(dev)-gen equals 4,
   and is_backlight_combination_mode() returns 0x4000.
 
 
 But to say it again in your words:   :-)
 
   [drm:is_backlight_combination_mode], BLM_COMBINATION_MODE = 1073741824  
 (0x4000)
 
 6x during boot-up, and several times later when changing the backlight
 brightness.
 
 
 This was with 8b061610dac3a3b89770c85ad63b481a47b0c38e. And now
 I have a little shocker for you (and me): because this was a
 vanilla kernel (apart from these debug messages), the screen went
 black again, like I knew it. But pressing the brightness down
 key turns the backlight on! I can't believe that I haven't tested
 that. I guess I've only tried brightness up and display toggle.
 Those don't turn backlight on. Or maybe somethine else relevant
 meanwhile changed in the i915 drivers. (I've regularly been
 updating to HEAD.)  
 
 So, the problem was just the initial state all the time?

Looks so, indeed.  Now, the question is what's the real cause.

IIRC, you reported that the backlight gets normal when you revert my
commit in 2.6.38.x.  So, this was regarded as a regression at first.
But, one question remains: whether the backlight level control worked
with the reverted kernel?
Judging from the attempts so far, it looks like that only LBPC can
adjust the level on your machine.  If it's true, 2.6.38.0 shouldn't be
able to adjust the level.  If you can still change the level without
LBPC, the former analysis was incorrect.

Also, with the latest 2.6.38.x, you found that the backlight gets back
when you adjust the level down.  Another question now is what happens
if you again turn it up to the max level.  Is the backlight still on?

If the backlight is kept on even with the max level, it implies that
the problem is only the initial value; once when set correctly, it'll
work fine after that.  OTOH, if the backlight gets off again at max,
it means that the max value (LBPC 0xfe) is a sort of out-of-range.
Then LBPC calculation in the driver has to be modified.


thanks,

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

[Bug 37193] Crash while switching between OpenGL window and other window

[bugzilla-daemon]

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

--- Comment #3 from Mathias Brodala i...@noctus.net 2011-05-15 03:12:32 PDT 
---
Created an attachment (id=46732)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46732)
X.org log file

-- 
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 37193] Crash while switching between OpenGL window and other window

[bugzilla-daemon]

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

--- Comment #4 from Mathias Brodala i...@noctus.net 2011-05-15 03:12:52 PDT 
---
Created an attachment (id=46733)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46733)
dmesg log file

-- 
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 37193] Crash while switching between OpenGL window and other window

[bugzilla-daemon]

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

--- Comment #5 from Mathias Brodala i...@noctus.net 2011-05-15 03:15:03 PDT 
---
(In reply to comment #2)
 Can you attach your xorg log and dmesg output?

Here they are. I tried to make sure that everything is written to disk by
running an endless loop calling sync but to no avail. The files contain no
traces at all from a crash or the like.

-- 
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 37220] New: RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-daemon]

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

   Summary: RS482: Screen starts flashing after screensaver with
KDE KWin desktop effects enabled
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: jlp.b...@gmail.com


After a very long time I have got my old laptop with integrated ATI Radeon
Xpress 200M. I remeber running it with desktop effects enabled and classic mesa
r300 driver just fine. Well now wit Gallium I have this annoying problem:

I have the screensaver set to Solar Winds from KDE's kdeartwork/screensaver
package. As usually I left the computer alone and when I came back and moved
the mouse screensaver turned off. But what started happening was that the
screen was flashing. Parts of it (rectangular) were becoming black or werw
coming from black to normal. Thoose parts are the parts that the mouse was
traveling over. Just as if the damaged areas which needed redrawing.

To make this go away I had to turn off the desktop effects (using
Alt+Shift+F12) and then turn them back on (with same keybiard shortcut).

The flashing effect is especially visible if I have the KDE's Screen Saver
control center module open and test OpenGL screensavers from there.

Reproducable: always

Software in use:
* mesa: git-bd5b7a6
* kde: 4.6.3
* xorg server: 1.10.1.901
* linux kernel: 2.6.39-rc7

-- 
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 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-daemon]

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

--- Comment #1 from Jure Repinc jlp.b...@gmail.com 2011-05-15 04:00:01 PDT ---
Created an attachment (id=46734)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46734)
dmesg

-- 
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 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-daemon]

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

--- Comment #2 from Jure Repinc jlp.b...@gmail.com 2011-05-15 04:00:39 PDT ---
Created an attachment (id=46735)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46735)
lspci

-- 
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 37220] RS482: Screen starts flashing after screensaver with KDE KWin desktop effects enabled

[bugzilla-daemon]

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

--- Comment #3 from Jure Repinc jlp.b...@gmail.com 2011-05-15 04:01:26 PDT ---
Created an attachment (id=46736)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46736)
Xorg.0.log

-- 
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 37227] New: z-buffer errors in doom3 outside the airlock

[bugzilla-daemon]

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

   Summary: z-buffer errors in doom3 outside the airlock
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: aaalmo...@gmail.com


Created an attachment (id=46742)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46742)
z-error.png

When the outer doors of the airlocks are open, the shadows inside the building
are drawn on top of everything (except the HUD). Disabling shadows in the
advanced settings makes them disappear. While being indoors, everything is
rendered correctly AFAICT.

With r300c every shadow was drawn on top of everything, but those covered the
HUD as well. This might be a similar problem.

-- 
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 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

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

--- Comment #13 from Milan Plzik eme...@gmail.com 2011-05-15 10:34:56 PDT ---
After more thorough testing, it seems that r300 driver is not able to correctly
create surfaces of certain dimensions; random vram content is shown instead.
Also, it doesn't seem to change, despite of application changing contents of
its window. I tried some more changes in the alignment table (like multiplying
related alignments by two), but it had only negative effect.

-- 
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 16687] Desktop corruption when enabling Desktop Effects

[bugzilla-daemon]

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

--- Comment #12 from almos aaalmo...@gmail.com 2011-05-15 10:54:25 PDT ---
Is this problem still around? According to comments #6 and #9 it is fixed in
the currently preferred codepath (KMS/DRI2/EXA).

 Sadly, Mozilla's opinion is that security comes from paying shitloads of
 money to VeriSign.  Hopefully they'll see the sense in publishing the
 CACert CA, and we'll have a CACert certificate, which will validate.
This is a known design flaw of SSL. See
http://blog.thoughtcrime.org/ssl-and-the-future-of-authenticity
for more information.

-- 
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: [RFC] drm: add overlays as first class KMS objects

[Clark, Rob]

On Fri, May 13, 2011 at 8:02 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Fri, 13 May 2011 18:16:30 +0200
 Daniel Vetter daniel.vet...@ffwll.ch wrote:

 Hi Jesse,

 Discussion here in Budapest with v4l and embedded graphics folks was
 extremely fruitful. A few quick things to take away - I'll try to dig
 through all
 the stuff I've learned more in-depth later (probably in a blog post or two):

Hi Daniel, thanks for writing this up

 - embedded graphics is insane. The output routing/blending/whatever
   currently shipping hw can do is crazy and kms as-is is nowhere near up
   to snuff to support this. We've discussed omap4 and a ti chip targeted at
   video surveillance as use cases. I'll post block diagrams and explanations
   some when later.

 Yeah I expected that; even just TVs can have really funky restrictions
 about z order and blend capability.

 - we should immediately stop to call anything an overlay. It's a confusing
   concept that has a different meaning in every subsystem and for every hw
   manufacturer. More sensible names are dma fifo engines for things that 
 slurp
   in planes and make them available to the display subsystem. Blend engines
   for blocks that take multiple input pipes and overlay/underlay/blend them
   together. Display subsytem/controller for the aggregate thing including
   encoders/resizers/outputs and especially the crazy routing network that
   connects everything.

 How about just display plane then?  Specifically in the context of
 display output hardware...

display plane could be a good name.. actually in omap4 case it is a
single dma engine that is multiplexing fetches for however many
attached video pipes.. that is perhaps an implementation detail, but
it makes display plane sound nicer as a name



 1) Splitting the crtc object into two objects: crtc with associated output 
 mode
 (pixel clock, encoders/connectors) and dma engines (possibly multiple) that
 feed it. omap 4 has essentially just 4 dma engines that can be freely 
 assigned
 to the available outputs, so a distinction between normal crtcs and overlay
 engines just does not make sense. There's the major open question of where
 to put the various attributes to set up the output pipeline. Also some of 
 these
 attributes might need to be changed atomicly together with pageflips on
 a bunch of dma engines all associated with the same crtc on the next vsync,
 e.g. output position of an overlaid video buffer.

 Yeah, that's a good goal, and pretty much what I had in mind here.
 However, breaking the existing interface is a non-starter, so either we
 need a new CRTC object altogether, or we preserve the idea of a
 primary plane (whatever that means for a given platform) that's tied
 to each CRTC, which each additional plane described in a separate
 structure.  Z order and blend restrictions will have to be communicated
 separately I think...

In the cases I can think of, you'll always have a primary plane, so
userspace need not explicitly specify it.  But I think you want the
driver to pick which display plane to be automatically hooked between
the primary fb and crtc, or at least this should be the case if some
new bit is set in driver_features to indicate the driver supports
multiple display planes per crtc.

BR,
-R

 Thanks,
 --
 Jesse Barnes, Intel Open Source Technology Center

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

Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Hans Verkuil]

On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
 Em 14-05-2011 13:02, Hans Verkuil escreveu:
  On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
 
  So, based at all I've seen, I'm pretty much convinced that the normal MMAP
  way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
  are not the best way to share data with framebuffers.
  
  I agree with that, but it is a different story between two V4L2 devices. 
  There
  you obviously want to use the streaming ioctls and still share buffers.
 
 I don't think so. the requirement for syncing the framebuffer between the two
 V4L2 devices is pretty much the same as we have with one V4L2 device and one 
 GPU.
 
 On both cases, the requirement is to pass a framebuffer between two entities, 
 and not a video stream.
 
 For example, imagine something like:
 
   V4L2 camera = V4L2 encoder t MPEG2
||
LL== GPU
 
 Both GPU and the V4L2 encoder should use the same logic to be sure that they 
 will
 use a buffer that were filled already by the camera. Also, the V4L2 camera
 driver can't re-use such framebuffer before being sure that both consumers 
 has already stopped using it.

No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
is a typical example where you want to queue/dequeue buffers. Especially since
the various parts of the pipeline may stall for a bit so you don't want to lose
frames. That's not what the overlay API is for, that's what our streaming API
gives us.

The use case above isn't even possible without copying. At least, I don't see a
way, unless the GPU buffer is non-destructive. In that case you can give the
frame to the GPU, and when the GPU is finished you can give it to the encoder.
I suspect that might become quite complex though.

Note that many video receivers cannot stall. You can't tell them to wait until
the last buffer finished processing. This is different from some/most? sensors.

So if you try to send the input of a video receiver to some device that requires
syncing which can cause stalls, then that will not work without losing frames.
Which especially for video encoding is not desirable.

Of course, it might be that we mean the same, but just use different words :-(

Regards,

Hans

 
 So, it is the same requirement as having four displays receiving such 
 framebuffer.
 
 Of course, a GPU endpoint may require some extra information for the blending,
 but also a V4L node may require some other type of extra information.
 
  We probably need
  something that it will be an enhanced version of the 
  VIDIOC_FBUF/VIDIOC_OVERLAY
  ioctls. Unfortunately, we can't just add more stuff there, as there's no
  reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's.
  
  That will be useful as well to add better support for blending and 
  Z-ordering
  between overlays. The old API for that is very limited in that respect.
 
 Agreed.
 
 Mauro.
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

[bugzilla-daemon]

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

--- Comment #8 from Brian Paterni bpate...@gmail.com 2011-05-15 14:10:45 PDT 
---
Update: CS: Source now successfully boots up to the menu! However I'm unsure
whether this is due to fix in mesa, wine, or libc6.

Though now if I attempt to start and load a game from the menu, everything
appears to go though smoothly until the last few bits are initialized. From
there I'm put into a loop of GPU lockups and GPU resets. Therefore this bug may
be related to #36421 now. The game still renders the match welcome screen
throughout these GPU lockup/reset cycles though, and I am able to eventually
switch to different workspace to kill the cstrike process.

Additionally, the in game stress test renders reasonably well until the camera
begins to enter the room with the transparent player model with flames behind
it (forgive me if I'm not using the correct terminology). At this point (before
the flames turn on) the stress test freezes and goes into the gpu reset loop
described above.

-- 
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 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

[bugzilla-daemon]

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

--- Comment #9 from Brian Paterni bpate...@gmail.com 2011-05-15 14:13:49 PDT 
---
Created an attachment (id=46749)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46749)
css kernel backtraces

-- 
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: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Alan Cox]

  On both cases, the requirement is to pass a framebuffer between two 
  entities, 
  and not a video stream.

It may not even be a framebuffer. In many cases you'll pass a framebuffer
or some memory target (in DRI think probably a GEM handle), in fact in
theory you can do much of this now.

  use a buffer that were filled already by the camera. Also, the V4L2 camera
  driver can't re-use such framebuffer before being sure that both consumers 
  has already stopped using it.

You also potentially need fences which complicates the interface
somewhat.

 The use case above isn't even possible without copying. At least, I don't see 
 a
 way, unless the GPU buffer is non-destructive. In that case you can give the
 frame to the GPU, and when the GPU is finished you can give it to the encoder.
 I suspect that might become quite complex though.

It's actually no different to giving a buffer to the GPU some of the time
and the CPU other bits. In those cases you often need to ensure private
ownership each side and do fencing/cache flushing as needed.

 Note that many video receivers cannot stall. You can't tell them to wait until
 the last buffer finished processing. This is different from some/most? 
 sensors.

A lot of video receivers also keep the bits away from the CPU as part of
the general DRM delusion TV operators work under. That means you've got
an object that has a handle, has operations (alpha, fade, scale, etc) but
you can never touch the bits. In the TV/Video world not unsurprisingly
that is often seen as the 'primary' frame buffer as well. You've got a
set of mappable framebuffers the CPU can touch plus other video sources
that can be mixed and placed but the CPU can only touch the mappable
objects that form part of the picture.

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

[PULL] drm-intel-next

[Keith Packard]

Here's most of the patches I'm hoping to land in 2.6.40:

 * Ivybridge support (Gen7)
 * Forcewake fixes for Sandybridge (And ivybridge).
 * Temporary FB for load detect (hoping for some cleanups here)

Still pending:

 * More modesetting cleanups (as always)
 * Disabling FBC on Ironlake to enable RC6 instead

This sequence also assigns me as the the drm/i915 maintainer.

The following changes since commit 2fb4e61d9471867677c97bf11dba8f1e9dfa7f7c:

  drm/i915/lvds: Only act on lid notify when the device is on (2011-05-09 
09:13:22 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git 
drm-intel-next

Ben Widawsky (10):
  drm/i915: fix ilk rc6 teardown locking
  drm/1915: ringbuffer wait for idle function
  drm/i915: fix rc6 initialization on Ironlake
  drm/i915: debugfs for context information
  drm/i915: proper use of forcewake
  drm/i915: reference counted forcewake
  drm/i915: forcewake struct mutex locking fixes
  drm/i915: move gen6 rps handling to workqueue
  drm/i915: debugfs interface for forcewake reference count
  drm/i915: forcewake debugfs fix

Chris Wilson (12):
  drm/i915: Move the irq wait queue initialisation into the ring init
  drm/i915: Simplify return value from intel_get_load_detect_pipe
  drm/i915: Propagate failure to set mode for load-detect pipe
  drm/i915: Don't store temporary load-detect variables in the generic 
encoder
  drm/i915: Remove unused supported_crtc from intel_load_detect_pipe
  drm/i915: Pass the saved adjusted_mode when adding to the load-detect crtc
  drm/i915: Remove dead code from intel_get_load_detect_pipe()
  drm/i915: Remove dead code from intel_release_load_detect_pipe()
  drm/i915: Attach a fb to the load-detect pipe
  drm/i915: Rename agp_type to cache_level
  drm/i915: Do not clflush snooped objects
  drm/i915: Disable all outputs early, before KMS takeover

Eric Anholt (12):
  drm/i915: Split the crtc_mode_set function along HAS_PCH_SPLIT() lines.
  drm/i915: Move the vblank pre/post modeset to the common crtc_mode_set.
  drm/i915: Remove the PCH paths from the pre-Ironlake crtc_mode_set().
  drm/i915: Drop the eDP paths from the pre-Ironlake crtc_mode_set.
  drm/i915: Drop the remaining bit of Ironlake code from 
i9xx_crtc_mode_set().
  drm/i915: Drop non-HAS_PCH_SPLIT() code from ironlake_crtc_mode_set().
  drm/i915: Drop remaining pre-Ironlake code from ironlake_crtc_mode_set().
  drm/i915: Clean up leftover DPLL and LVDS register choice from pch split.
  drm/i915: Fold the DPLL limit defines into the structs that use them.
  drm/i915: Use existing function instead of open-coding fence reg clear.
  drm/i915: Add support for fence registers on Ivybridge.
  drm/i915: Update the location of the ringbuffers' HWS_PGA registers for 
IVB.

Jesse Barnes (20):
  drm/i915: use i915_enable_rc6 on SNB too
  drm/i915: make FDI training a display function
  drm/i915: split irq handling into per-chipset functions
  drm/i915: split enable/disable vblank code into chipset specific functions
  drm/i915: add IS_GEN7 macro to cover Ivy Bridge and later
  drm/i915: add IS_IVYBRIDGE macro for checks
  drm/i915: Ivy Bridge has split display and pipe control
  drm/i915: add swizzle/tiling support for Ivy Bridge
  drm/i915: manual FDI training for Ivy Bridge
  drm/i915: treat Ivy Bridge watermarks like Sandy Bridge
  drm/i915: interrupt  vblank support for Ivy Bridge
  drm/i915: page flip support for Ivy Bridge
  drm/i915: ring support for Ivy Bridge
  agp/intel: add Ivy Bridge support
  drm/i915: add PantherPoint PCH ID
  drm/i915: add Ivy Bridge PCI IDs and driver feature structs
  drm/i915: set IBX pch type explicitly
  drm/i915: split clock gating init into per-chipset functions
  drm/i915: add Ivybridge clock gating init function
  drm/i915: split PCH clock gating init

Keith Packard (1):
  MAINTAINERS: Switch maintainer for drm/i915 to Keith Packard

 MAINTAINERS |4 +-
 drivers/char/agp/intel-agp.c|3 +
 drivers/char/agp/intel-agp.h|8 +
 drivers/char/agp/intel-gtt.c|   10 +
 drivers/gpu/drm/i915/i915_debugfs.c |  128 ++-
 drivers/gpu/drm/i915/i915_dma.c |   60 +-
 drivers/gpu/drm/i915/i915_drv.c |   61 +-
 drivers/gpu/drm/i915/i915_drv.h |  111 +-
 drivers/gpu/drm/i915/i915_gem.c |   36 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c |   35 +-
 drivers/gpu/drm/i915/i915_gem_tiling.c  |2 +-
 drivers/gpu/drm/i915/i915_irq.c |  310 -
 drivers/gpu/drm/i915/i915_reg.h |   35 +-
 drivers/gpu/drm/i915/i915_suspend.c |3 +-
 drivers/gpu/drm/i915/intel_crt.c|   24 +-
 drivers/gpu/drm/i915/intel_display.c| 2370 ++-
 

Re: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Rob Clark]

On Sun, May 15, 2011 at 4:27 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
  On both cases, the requirement is to pass a framebuffer between two 
  entities,
  and not a video stream.

 It may not even be a framebuffer. In many cases you'll pass a framebuffer
 or some memory target (in DRI think probably a GEM handle), in fact in
 theory you can do much of this now.

  use a buffer that were filled already by the camera. Also, the V4L2 camera
  driver can't re-use such framebuffer before being sure that both consumers
  has already stopped using it.

 You also potentially need fences which complicates the interface
 somewhat.

Presumable this is going through something like DRI2, so the client
application, which is what is interacting w/ V4L2 interface for camera
and perhaps video encoder, would call something that turns into a
ScheduleSwap() call on xserver side, returning a frame count to wait
for, and then at some point later ScheduleWaitMSC() to wait for that
frame count to know the GPU is done with the buffer.  The fences would
be buried somewhere within DRM (kernel) and xserver driver (userspace)
to keep the client app blocked until GPU is done.

You probably don't want the V4L2 devices to be too deeply connected to
how the GPU does synchronization, or otherwise V4L2 would need to
support each different DRM+xserver driver and how it implements buffer
synchronization with the GPU..

BR,
-R

 The use case above isn't even possible without copying. At least, I don't 
 see a
 way, unless the GPU buffer is non-destructive. In that case you can give the
 frame to the GPU, and when the GPU is finished you can give it to the 
 encoder.
 I suspect that might become quite complex though.

 It's actually no different to giving a buffer to the GPU some of the time
 and the CPU other bits. In those cases you often need to ensure private
 ownership each side and do fencing/cache flushing as needed.

 Note that many video receivers cannot stall. You can't tell them to wait 
 until
 the last buffer finished processing. This is different from some/most? 
 sensors.

 A lot of video receivers also keep the bits away from the CPU as part of
 the general DRM delusion TV operators work under. That means you've got
 an object that has a handle, has operations (alpha, fade, scale, etc) but
 you can never touch the bits. In the TV/Video world not unsurprisingly
 that is often seen as the 'primary' frame buffer as well. You've got a
 set of mappable framebuffers the CPU can touch plus other video sources
 that can be mixed and placed but the CPU can only touch the mappable
 objects that form part of the picture.

 Alan
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Bug 35192] New: BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=35192

   URL: http://bugs.gentoo.org/show_bug.cgi?id=359281
   Summary: BUG() in radeon driver with ATI Technologies Inc RV515
[Radeon X1300]
   Product: Drivers
   Version: 2.5
Kernel Version: 2.6.37 and 2.6.38
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: bluen...@gentoo.org
Regression: Yes


A regression in kernels 2.6.37 up to 2.6.38.6 hits a BUG() in the radeon driver
with the following hardware (as reported by lspci -kv)

02:00.0 VGA compatible controller: ATI Technologies Inc RV515 [Radeon X1300]
(prog-if 00 [VGA controller])
Subsystem: ATI Technologies Inc All-in-Wonder 2006 PCI-E Edition
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at fd9f (64-bit, non-prefetchable) [size=64K]
I/O ports at ce00 [size=256]
Expansion ROM at fd9c [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon


The BUG() is

kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle kernel paging request at 81c0e711
IP: [81c0e711] platform_device_register_resndata+0x0/0x8c
PGD 1ae5067 PUD 1ae9063 PMD 3c473063 PTE 81c0e163
Oops: 0011 [#1] SMP 
last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
CPU 0 
Pid: 1627, comm: X Tainted: GW   2.6.38.6 #1 HP Pavilion 061
ER900AA-ABA a1430n/NAGAMI
RIP: 0010:[81c0e711]  [81c0e711]
platform_device_register_resndata+0x0/0x8c
RSP: 0018:88003a2b3d30  EFLAGS: 00010246
RAX:  RBX: 88003cb81000 RCX: 
RDX:  RSI: 81a41cbb RDI: 
RBP: 88003a2b3d88 R08:  R09: 
R10: 88003a34 R11: e000 R12: 
R13: 88003cb80800 R14: 88003abeaa80 R15: 0001
FS:  7f40b4c72880() GS:88003fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 81c0e711 CR3: 3a2a8000 CR4: 06f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process X (pid: 1627, threadinfo 88003a2b2000, task 88003d3ef1a0)
Stack:
 8133aa29  0001 88003a2b3de8
 811681fc 88003a2b3df8 88003abeaa80 88003cb80800
 0040 40786440 0078 88003a2b3ea8
Call Trace:
 [8133aa29] ? radeon_cp_init+0xd79/0x1180
 [811681fc] ? ext4_file_write+0x6c/0x2a0
 [81317439] drm_ioctl+0x389/0x4d0
 [81339cb0] ? radeon_cp_init+0x0/0x1180
 [8110ddfb] do_vfs_ioctl+0x9b/0x510
 [8110e2bf] sys_ioctl+0x4f/0x80
 [81002e2b] system_call_fastpath+0x16/0x1b
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 
RIP  [81c0e711] platform_device_register_resndata+0x0/0x8c
 RSP 88003a2b3d30
CR2: 81c0e711
---[ end trace f569524e57c84b79 ]---


More detail is avaiable in the following gentoo bug:

   http://bugs.gentoo.org/show_bug.cgi?id=359281


We're looking into doing the git-bisect now.

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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

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

--- Comment #14 from Marek Olšák mar...@gmail.com 2011-05-15 18:13:03 PDT ---
Created an attachment (id=46752)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46752
 Review: https://bugs.freedesktop.org/review?bug=35998attachment=46752

little experiment

(In reply to comment #13)
 After more thorough testing, it seems that r300 driver is not able to 
 correctly
 create surfaces of certain dimensions; random vram content is shown instead.

Not true. The r300 driver gets it right for all the other GPUs, it's just rs6xx
that is broken.

Please try the attached patch.

-- 
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

[git pull] final drm fixes

[Dave Airlie]

Hi Linus,

two regression fixes, one on Intel Q67 with semaphores, and one in the 
switcheroo code. One black screen on radeon problem, oops on undock fix,
and a couple of minor updates to some changed regs on newer radeon hw.

Dave.

The following changes since commit ca1376d10810bc2c20c8d0821a9ee04ca2507c01:

  Merge branch 'fix/asoc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 (2011-05-12 
12:41:30 -0700)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (3):
  drm/radeon/kms: fix tiling reg on fusion
  drm/radeon/kms: fix extended lvds info parsing
  drm/radeon/kms: add some evergreen/ni safe regs

Andy Lutomirski (1):
  drm/i915: Revert i915.semaphore=1 default from 47ae63e0

Chris Wilson (1):
  drm: Take lock around probes for drm_fb_helper_hotplug_event

Florian Mickler (1):
  vga_switcheroo: don't toggle-switch devices

 drivers/gpu/drm/drm_fb_helper.c   |   26 ++
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/radeon/evergreen.c|5 -
 drivers/gpu/drm/radeon/evergreend.h   |1 +
 drivers/gpu/drm/radeon/radeon_atombios.c  |   14 +++---
 drivers/gpu/drm/radeon/reg_srcs/cayman|1 +
 drivers/gpu/drm/radeon/reg_srcs/evergreen |1 +
 drivers/gpu/vga/vga_switcheroo.c  |6 +++---
 include/drm/drm_fb_helper.h   |2 +-
 9 files changed, 45 insertions(+), 13 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.

[bugzilla-daemon]

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

--- Comment #5 from Tom Stellard tstel...@gmail.com 2011-05-15 22:01:41 PDT 
---
Created an attachment (id=46753)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46753
 Review: https://bugs.freedesktop.org/review?bug=36753attachment=46753

Verbose patch

The patch will give me some extra debug info.  Can you apply it and post the
output of RADEON_DEBUG=fp.

-- 
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