Re: [PATCH 2/2] i915: Apply the pipe A force quirk to some more models

[Chris Wilson]

On Sun, 20 Mar 2011 23:09:38 +, Ben Hutchings  wrote:
> Add some more IDs as listed in the old X driver.
> 
> Signed-off-by: Ben Hutchings 
> ---
> Is there some reason these were omitted from the kernel driver?

Yes, because they are non-gen2 chipsets and should have never needed the
pipe-A quirk.

*If* the quirk did indeed and still does help those systems, then we need
to root cause the real bug.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35483] New: util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c

[bugzilla-daemon]

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

   Summary: util_blit_pixels_writemask: crash in line 322 of
src/gallium/auxiliary/util/u_blit.c
   Product: Mesa
   Version: 7.10
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: deb...@carbon-project.org


Created an attachment (id=44648)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44648)
Backtrace of the crash (Tropico with Wine 1.3.16)

When switching to (or starting a game when the last setting was) the hardware
accelerated mode in Tropico, the game immediately crashes with the attached
backtrace.

Please note, that I wasn't able to attach an GDB to Wine/Tropic, if I do, I get
tons of SIGSEGVs in Tropico before I get anywhere close to this bug. So I fear
the Wine-generated backtrace must do. If you need further information, beyond
the following, please let me know.

DDX: 6.14.0
X.org: 1.9.4.901 (1.9.5 RC 1)
Kernel: 2.6.38
libdrm2: 2.4.24
Mesa: 7.10

The "Severity" was set in accordance with
 where a
crash is named as critical.

-- 
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: [PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G

[Chris Wilson]

On Sun, 20 Mar 2011 23:07:04 +, Ben Hutchings  wrote:
> Applying this quirk to the 855GM in all systems causes regressions
> (Debian bugs #493096, #619019).  Instead, apply the quirk to specific
> models as listed in the old X driver.
> 
> I don't see any explanation for this quirk being applied to the 845G,
> except perhaps that VT switching used to hang if pipe A was turned
> off.  However, that seems to be a problem only when using UMS.  So
> remove the quirk for the 845G as well.

The quirk should only be required for 830M due to the numerous instances
where a unit on the second pipe is actually wired into the clock on the
first pipe. (And so it is easiest to keep the first pipe active at all
times.)

I'd prefer the quirk table to disappear and simply be replaced by
IS_830M(). However, that requires testing and so should only be done
piecemeal. And leaves some doubt as to why the other machines were in the
quirk table in the first place.

Can you please repost each of these removals as a separate patch and lets
try and get a tested-by for each one? (Make sure the tester includes the
model name for his machine so we can double check the veracity of the
change.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares

[bugzilla-daemon]

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

--- Comment #9 from Fabio Pedretti  2011-03-21 01:39:02 
PDT ---
You could try with mesa from git master:
git pull git://anongit.freedesktop.org/mesa/mesa
It should be faster.

-- 
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 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares

[bugzilla-daemon]

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

--- Comment #10 from Fabio Pedretti  2011-03-21 01:43:48 
PDT ---
git clone git://anongit.freedesktop.org/mesa/mesa

-- 
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 35483] util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c

[bugzilla-daemon]

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

--- Comment #1 from Henri Verbeet  2011-03-21 02:28:04 PDT 
---
Created an attachment (id=44652)
 View: https://bugs.freedesktop.org/attachment.cgi?id=44652
 Review: https://bugs.freedesktop.org/review?bug=35483&attachment=44652

patch

You can't tell from the backtrace, but I think I know what this is. Wine
sometimes does FBO blits directly to the front buffer. This currently tends to
crash due to the front buffer surface not being created yet. The attached patch
should help with the crash, but it may not be enough to make the actual blit
work correctly.

-- 
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 35483] util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c

[bugzilla-daemon]

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

--- Comment #2 from Kai  2011-03-21 04:41:34 PDT ---
(In reply to comment #1)
> You can't tell from the backtrace, but I think I know what this is. Wine
> sometimes does FBO blits directly to the front buffer. This currently tends to
> crash due to the front buffer surface not being created yet. The attached 
> patch
> should help with the crash, but it may not be enough to make the actual blit
> work correctly.

Your guess was right, the patch from attachment 44652 fixes the bug. Tropico
works perfectly now with hardware 3D acceleration enabled (though it's a little
bit slow).

-- 
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 35502] New: Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

[bugzilla-daemon]

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

   Summary: Regression: black screen with Radeon KMS in 2.6.38
(2.6.37.4 worked fine)
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: john.lindg...@tds.net


Created an attachment (id=44669)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44669)
Kernel log

With Linux kernel 2.6.38, loading the radeon module causes the console to go
completely blank (laptop backlight on, but nothing displayed).  The system
still responds to ctrl-alt-del and reboots.  This is a regression from the
previous kernel, 2.6.37.4, where kernel mode setting works flawlessly.

With radeon.modeset=0, or with the module blacklisted, the system boots fine,
and I can use X, but without the powersaving features available through KMS.

System: Toshiba Satellite A305-S6916
Graphics: ATI Radeon Mobility HD 3650
Kernel: 2.6.38 (x86_64)

Kernel log when loading the module:

Mar 21 00:57:38 localhost kernel: [drm] Initialized drm 1.1.0 20060810
Mar 21 00:57:38 localhost kernel: [drm] radeon defaulting to kernel
modesetting.
Mar 21 00:57:38 localhost kernel: [drm] radeon kernel modesetting enabled.
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: PCI INT A ->  GSI 16
(level, low) ->  IRQ 16
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: setting latency timer to
64
Mar 21 00:57:38 localhost kernel: [drm] initializing kernel modesetting (RV635
0x1002:0x9591).
Mar 21 00:57:38 localhost kernel: [drm] register mmio base: 0xD630
Mar 21 00:57:38 localhost kernel: [drm] register mmio size: 65536
Mar 21 00:57:38 localhost kernel: ATOM BIOS: Tosh_IEC_Potomac_M86_DDR2
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: VRAM: 512M
0x - 0x1FFF (512M used)
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: GTT: 512M
0x2000 - 0x3FFF
Mar 21 00:57:38 localhost kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Mar 21 00:57:38 localhost kernel: [drm] RAM width 128bits DDR
Mar 21 00:57:38 localhost kernel: [TTM] Zone  kernel: Available graphics
memory: 2027544 kiB.
Mar 21 00:57:38 localhost kernel: [TTM] Initializing pool allocator.
Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of VRAM memory ready
Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of GTT memory ready.
Mar 21 00:57:38 localhost kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Mar 21 00:57:38 localhost kernel: [drm] Driver supports precise vblank
timestamp query.
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: irq 49 for MSI/MSI-X
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: radeon: using MSI.
Mar 21 00:57:38 localhost kernel: [drm] radeon: irq initialized.
Mar 21 00:57:38 localhost kernel: [drm] GART: num cpu pages 131072, num gpu
pages 131072
Mar 21 00:57:38 localhost kernel: [drm] Loading RV635 Microcode
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: WB enabled
Mar 21 00:57:38 localhost kernel: [drm] ring test succeeded in 1 usecs
Mar 21 00:57:38 localhost kernel: [drm] radeon: ib pool ready.
Mar 21 00:57:38 localhost kernel: [drm] ib test succeeded in 0 usecs
Mar 21 00:57:38 localhost kernel: [drm] Enabling audio support
Mar 21 00:57:38 localhost kernel: HDMI hot plug event: Pin=3 Presence_Detect=0
ELD_Valid=0

If there is any more info I can provide, please ask.

-- 
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 PATCH v2] Utilize the PCI API in the TTM framework.

[Michel Dänzer]

On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote: 
> 
> 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> but figured it would make first sense to get your guys input before heading 
> that route.

It's worse than unsightly: It breaks TTM on PPC. See
arch/powerpc/include/asm/dma-mapping.h: get_dma_ops() returns NULL if
NULL is passed in for the device, and most of its callers BUG in that
case. The exception being dma_supported(), so a possible solution might
be to use that for checking if dma_alloc_coherent can be used.

Dave, please prevent this change from entering mainline before there's a
solution for this.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

[bugzilla-daemon]

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

--- Comment #1 from Alex Deucher  2011-03-21 07:23:42 PDT ---
Can you bisect?

-- 
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 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

[bugzilla-daemon]

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

--- Comment #2 from John Lindgren  2011-03-21 07:42:40 
PDT ---
I will see if I can find the time.  Probably not before this weekend.

-- 
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: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven  wrote:

> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
> 
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame 
> buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...

We support panic these days as well, but people still don't like seeing
them. :)

The DRM KMS APIs provide everything fbdev provides, plus memory
management, a way to expose acceleration (via GEM or TTM), and a way to
manage multiple outputs reasonably.

> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.

There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34088] Update autotools configuration

[bugzilla-daemon]

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

Javier Jardón  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Javier Jardón  2011-03-21 11:19:43 PDT 
---
Committed in commit
http://cgit.freedesktop.org/mesa/drm/commit/?id=fd3ed34a2070fca3804baf54ece40d0bc2666226Commited
in commit

-- 
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: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic  wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using KMS directly?

Used by what?  All three major GPU device classes have KMS support
(Intel, ATI, and nVidia).  If you want it for a particular device, you
can always port it over.

As for fbdev emulation, what's still using it?  There's nothing
stopping projects from converting over; X and Wayland can already
handle KMS APIs just fine.

> I know the graphic driver situation is quite bad on Linux, especially
> on the embedded world. Fbdev seems is still quite used there by binary
> blob drivers.

Probably for a couple of reasons:
  1) inertia: fbdev has been around a lot longer, and provides most of
  what embedded devices need anyway
  2) feature set: why bother doing a full KMS driver if you're not
  going to use any of the additional features it would provide (output
  management, memory management, execution management)

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

Re: Future desktop on dumb frame buffers?

[timofonic timofonic]

Hello.

I have some rants and questions about fbdev, KMS and graphics stuff to
Linux. I'm just a mere user and occasional system administrator (and
going to start computer programming soon), but I hope to be able to
understand this situation better.

So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it seems) instead using KMS directly?

I know the graphic driver situation is quite bad on Linux, especially
on the embedded world. Fbdev seems is still quite used there by binary
blob drivers.

I was a fan of projects like DirectFB and such, but it seems they lack
the manpower or fuel to keep the project relevant. Maybe Wayland can
be their substitute and even have a broader usage too.

I hope KMS gets stronger and the graphic drivers get more into the
open source world (instead violating GPL and doing an attitude I think
should be illegal), that news about open source PowerVR SGX drivers
seems very positive (and surprising, because Imagination Technologies
seems quite against FOSS).

I hope all this gets to suck a bit less. Linux graphics stack
foundation based on KMS, TTM/GEM, advanced hardware accelerated video
decoding of most formats (by using OpenCL plus FFMpeg/LibAV, for
example), Gallium3D and full OpenGL 4.x support could make me very
happy as user and future developer...

Sadly, stuff like S3TC and such makes me very sad. I hope it gets
resolved sucessfully, patents are the nightmare of the technology...


Regards.

On Mon, Mar 21, 2011 at 6:00 PM, Jesse Barnes  wrote:
> On Sat, 19 Mar 2011 12:20:24 +0100
> Geert Uytterhoeven  wrote:
>
>> As noone responded to my question in
>> http://www.spinics.net/lists/dri-devel/msg08851.html
>> (yes, it was a bit hidden in a thread), I'm asking it here again (and
>> also on the Wayland
>> mailing list).
>>
>> Basically I'm still puzzled about this KMS thing. If the name "Kernel
>> Mode Setting"
>> covers it, then how does it compare to plain fbdev? Just additional frame 
>> buffer
>> memory management?
>> Also, some people may remember we did have kernel messages (e.g. oops, panic)
>> on graphical consoles with fbdev, until people started not liking them
>> showing up
>> on their X desktops...
>
> We support panic these days as well, but people still don't like seeing
> them. :)
>
> The DRM KMS APIs provide everything fbdev provides, plus memory
> management, a way to expose acceleration (via GEM or TTM), and a way to
> manage multiple outputs reasonably.
>
>> Furthermore, everybody states that "future desktop" (that's
>> http://wayland.freedesktop.org/)
>> will require KMS drivers.
>> How do/will we handle this on dumb frame buffers? It's not like we can't do
>> "advanced" things like compositing using the CPU. Transparency may stretch
>> it a bit on lower end CPUs, but you don't always need that.
>
> There's nothing in DRM that precludes doing simple fbdev-like drivers
> as well, though for many embedded uses I wouldn't expect it to provide
> a whole lot of benefit.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Future desktop on dumb frame buffers?

[Corbin Simpson]

On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes  wrote:
> On Mon, 21 Mar 2011 19:19:43 +
> timofonic timofonic  wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what?  All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia).  If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it?  There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
>
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
>  1) inertia: fbdev has been around a lot longer, and provides most of
>  what embedded devices need anyway
>  2) feature set: why bother doing a full KMS driver if you're not
>  going to use any of the additional features it would provide (output
>  management, memory management, execution management)

Related: We are still missing basic userspace tools (kmsset, e.g.),
some kind of direct KMS console (kmscon would work, if it existed),
and an xf86-video-modesetting which compiles and works (this is
actually possible now, with some patches that landed in 2.6.38 for
generic KMS access.)

This is important to me, as the various old drivers I've been hacking
on won't be accepted upstream without some sort of userspace which can
work with them. One of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

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

Re: Future desktop on dumb frame buffers?

[Geert Uytterhoeven]

On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  wrote:
> On Mon, 21 Mar 2011 19:19:43 +
> timofonic timofonic  wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what?  All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia).  If you want it for a particular device, you
> can always port it over.

The three major GPU device classes on PC...

> As for fbdev emulation, what's still using it?  There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.

Can Wayland handle fbdev APIs ...

>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
>  1) inertia: fbdev has been around a lot longer, and provides most of
>  what embedded devices need anyway
>  2) feature set: why bother doing a full KMS driver if you're not
>  going to use any of the additional features it would provide (output
>  management, memory management, execution management)

... if no additional features of KMS are needed?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven  wrote:

> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic  wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what?  All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
> > can always port it over.
> 
> The three major GPU device classes on PC...

Yes, good point. :)

> > As for fbdev emulation, what's still using it?  There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> 
> Can Wayland handle fbdev APIs ...

Yes.  Fundamentally, the Wayland protocol just assumes a way to share
buffers between processes.  For the software raster version of the Qt
port, Kristian created a shmem interface for doing that to allow the
results of CPU rendering to be passed around without copying.  On an
embedded device that would be one way to go.

-- 
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: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 12:34:38 -0700
Corbin Simpson  wrote:
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)

Yeah, we used to call that drmcon, and it's still a big open.  I think
there are some projects that sit on top of fbdev and provide a good
text console with fancy character and input support, but I don't know
if any of them have been ported to KMS to handle multiple outputs or
with an aim toward integrating into a distro as a VT replacement.

kmsset or something would be pretty easy to do; the modetest program in
the drm repo would be a good starting point for that.  One limitation
there is handling fbcon, which makes reallocation of the framebuffer
somewhat difficult.

IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...

-- 
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: Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
 wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  wrote:
>> On Mon, 21 Mar 2011 19:19:43 +
>> timofonic timofonic  wrote:
>>> So if KMS is so cool and provides many advantages over fbdev and
>>> such... Why isn't more widely used intead of still relying on fbdev?
>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>> it seems) instead using KMS directly?
>>
>> Used by what?  All three major GPU device classes have KMS support
>> (Intel, ATI, and nVidia).  If you want it for a particular device, you
>> can always port it over.
>
> The three major GPU device classes on PC...

Sadly it gets worse.  A lot of the SoC vendors are adding an fbdev
emulation layer on top of v4l rather than using fbdev directly or
using KMS and v4l has grown it's own edid, hdmi, and cec handling.

Alex

>
>> As for fbdev emulation, what's still using it?  There's nothing
>> stopping projects from converting over; X and Wayland can already
>> handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
>
>>> I know the graphic driver situation is quite bad on Linux, especially
>>> on the embedded world. Fbdev seems is still quite used there by binary
>>> blob drivers.
>>
>> Probably for a couple of reasons:
>>  1) inertia: fbdev has been around a lot longer, and provides most of
>>  what embedded devices need anyway
>>  2) feature set: why bother doing a full KMS driver if you're not
>>  going to use any of the additional features it would provide (output
>>  management, memory management, execution management)
>
> ... if no additional features of KMS are needed?
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
>                                 -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Future desktop on dumb frame buffers?

[Alan Cox]

>   1) inertia: fbdev has been around a lot longer, and provides most of
>   what embedded devices need anyway
>   2) feature set: why bother doing a full KMS driver if you're not
>   going to use any of the additional features it would provide (output
>   management, memory management, execution management)

3) its got documentation

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

Re: Future desktop on dumb frame buffers?

[Ondrej Zary]

On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes  
wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> >
> > timofonic timofonic  wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what?  All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
> > can always port it over.
> >
> > As for fbdev emulation, what's still using it?  There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> >
> >> I know the graphic driver situation is quite bad on Linux, especially
> >> on the embedded world. Fbdev seems is still quite used there by binary
> >> blob drivers.
> >
> > Probably for a couple of reasons:
> >  1) inertia: fbdev has been around a lot longer, and provides most of
> >  what embedded devices need anyway
> >  2) feature set: why bother doing a full KMS driver if you're not
> >  going to use any of the additional features it would provide (output
> >  management, memory management, execution management)
>
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)

This looks interesting. If existing *fb drivers could be easily converted to 
KMS (including 2D acceleration) and then used in X with a common driver, it 
would be great. Let's say, convert cyber2000fb driver to KMS and use it in X 
with 2D acceleration.

> This is important to me, as the various old drivers I've been hacking
> on won't be accepted upstream without some sort of userspace which can
> work with them. One of the big goals of KMS was a generic
> userspace-facing API, like FB, but without the suck.


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

Re: Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 21:20:08 +
Alan Cox  wrote:

> >   1) inertia: fbdev has been around a lot longer, and provides most of
> >   what embedded devices need anyway
> >   2) feature set: why bother doing a full KMS driver if you're not
> >   going to use any of the additional features it would provide (output
> >   management, memory management, execution management)
> 
> 3) its got documentation

Jeez, some people want it all.

You looking for docs for the ioctls and such?

-- 
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: Future desktop on dumb frame buffers?

[Matt Turner]

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox  wrote:
>>   1) inertia: fbdev has been around a lot longer, and provides most of
>>   what embedded devices need anyway
>>   2) feature set: why bother doing a full KMS driver if you're not
>>   going to use any of the additional features it would provide (output
>>   management, memory management, execution management)
>
> 3) its got documentation

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.

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

Re: Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary  wrote:
> On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
>> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes 
> wrote:
>> > On Mon, 21 Mar 2011 19:19:43 +
>> >
>> > timofonic timofonic  wrote:
>> >> So if KMS is so cool and provides many advantages over fbdev and
>> >> such... Why isn't more widely used intead of still relying on fbdev?
>> >> Why still using fbdev emulation (that is partial and somewhat broken,
>> >> it seems) instead using KMS directly?
>> >
>> > Used by what?  All three major GPU device classes have KMS support
>> > (Intel, ATI, and nVidia).  If you want it for a particular device, you
>> > can always port it over.
>> >
>> > As for fbdev emulation, what's still using it?  There's nothing
>> > stopping projects from converting over; X and Wayland can already
>> > handle KMS APIs just fine.
>> >
>> >> I know the graphic driver situation is quite bad on Linux, especially
>> >> on the embedded world. Fbdev seems is still quite used there by binary
>> >> blob drivers.
>> >
>> > Probably for a couple of reasons:
>> >  1) inertia: fbdev has been around a lot longer, and provides most of
>> >  what embedded devices need anyway
>> >  2) feature set: why bother doing a full KMS driver if you're not
>> >  going to use any of the additional features it would provide (output
>> >  management, memory management, execution management)
>>
>> Related: We are still missing basic userspace tools (kmsset, e.g.),
>> some kind of direct KMS console (kmscon would work, if it existed),
>> and an xf86-video-modesetting which compiles and works (this is
>> actually possible now, with some patches that landed in 2.6.38 for
>> generic KMS access.)
>
> This looks interesting. If existing *fb drivers could be easily converted to
> KMS (including 2D acceleration) and then used in X with a common driver, it
> would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
> with 2D acceleration.

You'd need to update the existing DDX to work with KMS.  Generally you
need some sort of userspace driver to allocate the buffers, deal with
acceleration alignment, build the acceleration command buffers, and
interface with X.

Alex

>
>> This is important to me, as the various old drivers I've been hacking
>> on won't be accepted upstream without some sort of userspace which can
>> work with them. One of the big goals of KMS was a generic
>> userspace-facing API, like FB, but without the suck.
>
>
> --
> Ondrej Zary
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

OT: sending patches to the list (was: [PATCH] kernel/drm: vblank wait on crtc > 1)

[Paul Menzel]

Am Sonntag, den 20.03.2011, 18:47 -0500 schrieb Ilija Hadzic:
> sorry about that, I use pine and thought that's as plain as it gets. I 
> guess next time I'll try just 'mail' from command line.

Or `git send-email`¹.


Thanks,

Paul


¹ manual: `git help send-email`


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel Dänzer wrote:
> On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote: 
> > 
> > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> > but figured it would make first sense to get your guys input before heading 
> > that route.
> 
> It's worse than unsightly: It breaks TTM on PPC. See
> arch/powerpc/include/asm/dma-mapping.h: get_dma_ops() returns NULL if
> NULL is passed in for the device, and most of its callers BUG in that
> case. The exception being dma_supported(), so a possible solution might
> be to use that for checking if dma_alloc_coherent can be used.
> 
> Dave, please prevent this change from entering mainline before there's a
> solution for this.

We do have a fix for it: 

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
devel/ttm.pci-api.v5

Can you tell me if that works for you?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30832] Radeon S-Video Out has become black and white. Works fine in 2.6.37

[bugzilla-daemon]

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





--- Comment #5 from Arbit Rabbit   2011-03-22 00:09:34 
---
Seems to work for me, thanks.

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

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
--
___
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

Re: [PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G

[Ben Hutchings]

On Mon, 2011-03-21 at 07:38 +, Chris Wilson wrote:
> On Sun, 20 Mar 2011 23:07:04 +, Ben Hutchings  
> wrote:
> > Applying this quirk to the 855GM in all systems causes regressions
> > (Debian bugs #493096, #619019).  Instead, apply the quirk to specific
> > models as listed in the old X driver.
> > 
> > I don't see any explanation for this quirk being applied to the 845G,
> > except perhaps that VT switching used to hang if pipe A was turned
> > off.  However, that seems to be a problem only when using UMS.  So
> > remove the quirk for the 845G as well.
> 
> The quirk should only be required for 830M due to the numerous instances
> where a unit on the second pipe is actually wired into the clock on the
> first pipe. (And so it is easiest to keep the first pipe active at all
> times.)

When you say 'wired into', is this part of the chip design or something
done on the board?

Jesse, why did you add the quirk for other chips?

> I'd prefer the quirk table to disappear and simply be replaced by
> IS_830M(). However, that requires testing and so should only be done
> piecemeal. And leaves some doubt as to why the other machines were in the
> quirk table in the first place.

The commit messages referring to VT switching suggest that the problems
related to disabling part A may actually have been related to handover
to the console driver before KMS.

> Can you please repost each of these removals as a separate patch and lets
> try and get a tested-by for each one? (Make sure the tester includes the
> model name for his machine so we can double check the veracity of the
> change.)

I already have 4 regression reports for the addition of the quirk for
855GM:

http://bugs.debian.org/618665
http://bugs.debian.org/618997
http://bugs.debian.org/619019
http://bugs.debian.org/619192

and one on an unidentified (as yet) chip:

http://bugs.debian.org/619199

So I can just send a patch to revert 855GM.

The odd thing about these reports is that the regression is reported to
occur before the system has ever been suspended, and to be fixed (or
mitigated) by suspending and resuming.  I don't understand why the quirk
even comes into play during boot.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 35531] New: Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

[bugzilla-daemon]

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

   Summary: Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel
blows up
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
   URL: https://bugs.gentoo.org/show_bug.cgi?id=349247
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: chris2...@hotmail.com


Created an attachment (id=44703)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44703)
dmesg output from a successful attempt

When booting up Xorg server 1.9.2 with xf86-video-ati-6.14.0 and kernel
2.6.36-gentoo-r5 (distro-patched kernel, but the same problem doesn't appear in
2.6.35-g-r12), as soon as X starts, my monitor goes into DPMS powersave and I
get backtraces in dmesg.

A Gentoo developer suggested booting with kernel command-line parameter
"radeon.agpmode=-1". This didn't help.

I've attached dmesg output from a successful startup with 2.6.35, and will
attach dmesg output from failed startups with and without agpmode=-1
momentarily (looks like only one file can be attached at bug creation time).

-- 
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 35531] Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

[bugzilla-daemon]

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

--- Comment #1 from Christopher Head  2011-03-21 
21:26:26 PDT ---
Created an attachment (id=44704)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44704)
dmesg output from a failed attempt

-- 
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 35531] Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

[bugzilla-daemon]

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

--- Comment #2 from Christopher Head  2011-03-21 
21:26:41 PDT ---
Created an attachment (id=44705)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44705)
dmesg output with radeon.agpmode=-1

-- 
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 35531] Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

[bugzilla-daemon]

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

--- Comment #3 from Dave Airlie  2011-03-21 21:42:27 
PDT ---
that kernel doesn't have KMS enabled which is probably not what you want.

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

[PATCH] drm/radeon/kms: prefer legacy pll algo for tv-out

[Alex Deucher]

ntsc seems to work fine with either algo, some
pal TVs seem pickier.

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

Signed-off-by: Alex Deucher 
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/atombios_crtc.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 3cd3234..10e41af 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -957,7 +957,11 @@ static void atombios_crtc_set_pll(struct drm_crtc *crtc, 
struct drm_display_mode
/* adjust pixel clock as needed */
adjusted_clock = atombios_adjust_pll(crtc, mode, pll, ss_enabled, &ss);
 
-   if (ASIC_IS_AVIVO(rdev))
+   if (radeon_encoder->active_device & (ATOM_DEVICE_TV_SUPPORT))
+   /* TV seems to prefer the legacy algo on some boards */
+   radeon_compute_pll_legacy(pll, adjusted_clock, &pll_clock, 
&fb_div, &frac_fb_div,
+ &ref_div, &post_div);
+   else if (ASIC_IS_AVIVO(rdev))
radeon_compute_pll_avivo(pll, adjusted_clock, &pll_clock, 
&fb_div, &frac_fb_div,
 &ref_div, &post_div);
else
-- 
1.7.1.1

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

[PATCH] kernel/drm: vblank wait on crtc > 1

[Dave Airlie]

On Sat, Mar 19, 2011 at 7:58 AM, Ilija Hadzic
 wrote:
>
> Hi Dave,
>
> Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds the
> capability to wait on vblank events for CRTCs that are greater than 1 and
> thus cannot be represented with primary/secondary flags in the legacy
> interface. It was discussed on the dri-devel list in these two threads:
>
> http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
> http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html
>
> This patch extends the interface to drm_wait_vblank ioctl so that crtc>1 can
> be represented. It also adds a new capability to drm_getcap ioctl so that
> the user space can check whether the new interface to drm_wait_vblank is
> supported (and fall back to the legacy interface if not)

Yeah I'm happy with this, however your mail reader seems to have eaten
the patch.

I've rescued it locally, but next time please make sure the patch
hasn't been whitespace damaged on the way out.

lots of spaces before tabs added.

Dave.

[PATCH] drm: check for modesetting on modeset ioctls

[Dave Airlie]

From: Dave Airlie 

Noticed this while working on some other things, helps if we check for modeset
enabled on modesetting ioctls.

Cc: stable at kernel.org
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_crtc.c |   51 
 1 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4c95b5f..799e149 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1073,6 +1073,9 @@ int drm_mode_getresources(struct drm_device *dev, void 
*data,
uint32_t __user *encoder_id;
struct drm_mode_group *mode_group;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);

/*
@@ -1244,6 +1247,9 @@ int drm_mode_getcrtc(struct drm_device *dev,
struct drm_mode_object *obj;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);

obj = drm_mode_object_find(dev, crtc_resp->crtc_id,
@@ -1312,6 +1318,9 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
uint64_t __user *prop_values;
uint32_t __user *encoder_ptr;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));

DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id);
@@ -1431,6 +1440,9 @@ int drm_mode_getencoder(struct drm_device *dev, void 
*data,
struct drm_encoder *encoder;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);
obj = drm_mode_object_find(dev, enc_resp->encoder_id,
   DRM_MODE_OBJECT_ENCODER);
@@ -1486,6 +1498,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
int ret = 0;
int i;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);
obj = drm_mode_object_find(dev, crtc_req->crtc_id,
   DRM_MODE_OBJECT_CRTC);
@@ -1603,6 +1618,9 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
struct drm_crtc *crtc;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
if (!req->flags) {
DRM_ERROR("no operation set\n");
return -EINVAL;
@@ -1667,6 +1685,9 @@ int drm_mode_addfb(struct drm_device *dev,
struct drm_framebuffer *fb;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
if ((config->min_width > r->width) || (r->width > config->max_width)) {
DRM_ERROR("mode new framebuffer width not within limits\n");
return -EINVAL;
@@ -1724,6 +1745,9 @@ int drm_mode_rmfb(struct drm_device *dev,
int ret = 0;
int found = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);
obj = drm_mode_object_find(dev, *id, DRM_MODE_OBJECT_FB);
/* TODO check that we realy get a framebuffer back. */
@@ -1780,6 +1804,9 @@ int drm_mode_getfb(struct drm_device *dev,
struct drm_framebuffer *fb;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);
obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB);
if (!obj) {
@@ -1813,6 +1840,9 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
int num_clips;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);
obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB);
if (!obj) {
@@ -1996,6 +2026,9 @@ int drm_mode_attachmode_ioctl(struct drm_device *dev,
struct drm_mode_modeinfo *umode = &mode_cmd->mode;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);

obj = drm_mode_object_find(dev, mode_cmd->connector_id, 
DRM_MODE_OBJECT_CONNECTOR);
@@ -2042,6 +2075,9 @@ int drm_mode_detachmode_ioctl(struct drm_device *dev,
struct drm_mode_modeinfo *umode = &mode_cmd->mode;
int ret = 0;

+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
mutex_lock(&dev->mode_config.mutex);

obj = drm_mode_object_find(dev, mode_cmd->connector_id, 
DRM_MODE_OBJECT_CONNECTOR);
@@ -2211,6 +2247,9 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
uint64_t __user *values_ptr;
uint32_t __user *b

[PATCH] drm: check for modesetting on modeset ioctls

[Alex Deucher]

On Sun, Mar 20, 2011 at 8:03 PM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> Noticed this while working on some other things, helps if we check for modeset
> enabled on modesetting ioctls.

Seems like a good plan to me.

Reviewed-by: Alex Deucher 

>
> Cc: stable at kernel.org
> Signed-off-by: Dave Airlie 
> ---
> ?drivers/gpu/drm/drm_crtc.c | ? 51 
> 
> ?1 files changed, 51 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 4c95b5f..799e149 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1073,6 +1073,9 @@ int drm_mode_getresources(struct drm_device *dev, void 
> *data,
> ? ? ? ?uint32_t __user *encoder_id;
> ? ? ? ?struct drm_mode_group *mode_group;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
>
> ? ? ? ?/*
> @@ -1244,6 +1247,9 @@ int drm_mode_getcrtc(struct drm_device *dev,
> ? ? ? ?struct drm_mode_object *obj;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
>
> ? ? ? ?obj = drm_mode_object_find(dev, crtc_resp->crtc_id,
> @@ -1312,6 +1318,9 @@ int drm_mode_getconnector(struct drm_device *dev, void 
> *data,
> ? ? ? ?uint64_t __user *prop_values;
> ? ? ? ?uint32_t __user *encoder_ptr;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
>
> ? ? ? ?DRM_DEBUG_KMS("[CONNECTOR:%d:?]\n", out_resp->connector_id);
> @@ -1431,6 +1440,9 @@ int drm_mode_getencoder(struct drm_device *dev, void 
> *data,
> ? ? ? ?struct drm_encoder *encoder;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?obj = drm_mode_object_find(dev, enc_resp->encoder_id,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DRM_MODE_OBJECT_ENCODER);
> @@ -1486,6 +1498,9 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
> ? ? ? ?int ret = 0;
> ? ? ? ?int i;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?obj = drm_mode_object_find(dev, crtc_req->crtc_id,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? DRM_MODE_OBJECT_CRTC);
> @@ -1603,6 +1618,9 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
> ? ? ? ?struct drm_crtc *crtc;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?if (!req->flags) {
> ? ? ? ? ? ? ? ?DRM_ERROR("no operation set\n");
> ? ? ? ? ? ? ? ?return -EINVAL;
> @@ -1667,6 +1685,9 @@ int drm_mode_addfb(struct drm_device *dev,
> ? ? ? ?struct drm_framebuffer *fb;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?if ((config->min_width > r->width) || (r->width > config->max_width)) {
> ? ? ? ? ? ? ? ?DRM_ERROR("mode new framebuffer width not within limits\n");
> ? ? ? ? ? ? ? ?return -EINVAL;
> @@ -1724,6 +1745,9 @@ int drm_mode_rmfb(struct drm_device *dev,
> ? ? ? ?int ret = 0;
> ? ? ? ?int found = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?obj = drm_mode_object_find(dev, *id, DRM_MODE_OBJECT_FB);
> ? ? ? ?/* TODO check that we realy get a framebuffer back. */
> @@ -1780,6 +1804,9 @@ int drm_mode_getfb(struct drm_device *dev,
> ? ? ? ?struct drm_framebuffer *fb;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB);
> ? ? ? ?if (!obj) {
> @@ -1813,6 +1840,9 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> ? ? ? ?int num_clips;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB);
> ? ? ? ?if (!obj) {
> @@ -1996,6 +2026,9 @@ int drm_mode_attachmode_ioctl(struct drm_device *dev,
> ? ? ? ?struct drm_mode_modeinfo *umode = &mode_cmd->mode;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
>
> ? ? ? ?obj = drm_mode_object_find(dev, mode_cmd->connector_id, 
> DRM_MODE_OBJECT_CONNECTOR);
> @@ -2042,6 +2075,9 @@ int drm_mode_detachmode_ioctl(struct drm_device *dev,
> ? ? ? ?struct drm_mode_modeinfo *umode = &mode_cmd->mode;
> ? ? ? ?int ret = 0;
>
> + ? ? ? if (!drm_core_check_feature(dev, DRIVER_MODESET))
>

[PATCH 2/2] i915: Apply the pipe A force quirk to some more models

[Chris Wilson]

On Sun, 20 Mar 2011 23:09:38 +, Ben Hutchings  
wrote:
> Add some more IDs as listed in the old X driver.
> 
> Signed-off-by: Ben Hutchings 
> ---
> Is there some reason these were omitted from the kernel driver?

Yes, because they are non-gen2 chipsets and should have never needed the
pipe-A quirk.

*If* the quirk did indeed and still does help those systems, then we need
to root cause the real bug.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 35483] New: util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c

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

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

   Summary: util_blit_pixels_writemask: crash in line 322 of
src/gallium/auxiliary/util/u_blit.c
   Product: Mesa
   Version: 7.10
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: debian at carbon-project.org


Created an attachment (id=44648)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44648)
Backtrace of the crash (Tropico with Wine 1.3.16)

When switching to (or starting a game when the last setting was) the hardware
accelerated mode in Tropico, the game immediately crashes with the attached
backtrace.

Please note, that I wasn't able to attach an GDB to Wine/Tropic, if I do, I get
tons of SIGSEGVs in Tropico before I get anywhere close to this bug. So I fear
the Wine-generated backtrace must do. If you need further information, beyond
the following, please let me know.

DDX: 6.14.0
X.org: 1.9.4.901 (1.9.5 RC 1)
Kernel: 2.6.38
libdrm2: 2.4.24
Mesa: 7.10

The "Severity" was set in accordance with
 where a
crash is named as critical.

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

[PATCH 1/2] i915: Remove pipe A force quirk for 855GM and 845G

[Chris Wilson]

On Sun, 20 Mar 2011 23:07:04 +, Ben Hutchings  
wrote:
> Applying this quirk to the 855GM in all systems causes regressions
> (Debian bugs #493096, #619019).  Instead, apply the quirk to specific
> models as listed in the old X driver.
> 
> I don't see any explanation for this quirk being applied to the 845G,
> except perhaps that VT switching used to hang if pipe A was turned
> off.  However, that seems to be a problem only when using UMS.  So
> remove the quirk for the 845G as well.

The quirk should only be required for 830M due to the numerous instances
where a unit on the second pipe is actually wired into the clock on the
first pipe. (And so it is easiest to keep the first pipe active at all
times.)

I'd prefer the quirk table to disappear and simply be replaced by
IS_830M(). However, that requires testing and so should only be done
piecemeal. And leaves some doubt as to why the other machines were in the
quirk table in the first place.

Can you please repost each of these removals as a separate patch and lets
try and get a tested-by for each one? (Make sure the tester includes the
model name for his machine so we can double check the veracity of the
change.)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares

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

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

--- Comment #9 from Fabio Pedretti  2011-03-21 01:39:02 
PDT ---
You could try with mesa from git master:
git pull git://anongit.freedesktop.org/mesa/mesa
It should be faster.

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

[Bug 32639] [RADEON::R300C] artifacts on dinoshade, neverball and other GL softwares

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

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

--- Comment #10 from Fabio Pedretti  2011-03-21 
01:43:48 PDT ---
git clone git://anongit.freedesktop.org/mesa/mesa

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

[Bug 35483] util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c

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

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

--- Comment #1 from Henri Verbeet  2011-03-21 02:28:04 
PDT ---
Created an attachment (id=44652)
 View: https://bugs.freedesktop.org/attachment.cgi?id=44652
 Review: https://bugs.freedesktop.org/review?bug=35483&attachment=44652

patch

You can't tell from the backtrace, but I think I know what this is. Wine
sometimes does FBO blits directly to the front buffer. This currently tends to
crash due to the front buffer surface not being created yet. The attached patch
should help with the crash, but it may not be enough to make the actual blit
work correctly.

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

[Bug 35483] util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c

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

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

--- Comment #2 from Kai  2011-03-21 04:41:34 PDT 
---
(In reply to comment #1)
> You can't tell from the backtrace, but I think I know what this is. Wine
> sometimes does FBO blits directly to the front buffer. This currently tends to
> crash due to the front buffer surface not being created yet. The attached 
> patch
> should help with the crash, but it may not be enough to make the actual blit
> work correctly.

Your guess was right, the patch from attachment 44652 fixes the bug. Tropico
works perfectly now with hardware 3D acceleration enabled (though it's a little
bit slow).

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

[Bug 35502] New: Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

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

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

   Summary: Regression: black screen with Radeon KMS in 2.6.38
(2.6.37.4 worked fine)
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: john.lindgren at tds.net


Created an attachment (id=44669)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44669)
Kernel log

With Linux kernel 2.6.38, loading the radeon module causes the console to go
completely blank (laptop backlight on, but nothing displayed).  The system
still responds to ctrl-alt-del and reboots.  This is a regression from the
previous kernel, 2.6.37.4, where kernel mode setting works flawlessly.

With radeon.modeset=0, or with the module blacklisted, the system boots fine,
and I can use X, but without the powersaving features available through KMS.

System: Toshiba Satellite A305-S6916
Graphics: ATI Radeon Mobility HD 3650
Kernel: 2.6.38 (x86_64)

Kernel log when loading the module:

Mar 21 00:57:38 localhost kernel: [drm] Initialized drm 1.1.0 20060810
Mar 21 00:57:38 localhost kernel: [drm] radeon defaulting to kernel
modesetting.
Mar 21 00:57:38 localhost kernel: [drm] radeon kernel modesetting enabled.
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: PCI INT A ->  GSI 16
(level, low) ->  IRQ 16
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: setting latency timer to
64
Mar 21 00:57:38 localhost kernel: [drm] initializing kernel modesetting (RV635
0x1002:0x9591).
Mar 21 00:57:38 localhost kernel: [drm] register mmio base: 0xD630
Mar 21 00:57:38 localhost kernel: [drm] register mmio size: 65536
Mar 21 00:57:38 localhost kernel: ATOM BIOS: Tosh_IEC_Potomac_M86_DDR2
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: VRAM: 512M
0x - 0x1FFF (512M used)
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: GTT: 512M
0x2000 - 0x3FFF
Mar 21 00:57:38 localhost kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Mar 21 00:57:38 localhost kernel: [drm] RAM width 128bits DDR
Mar 21 00:57:38 localhost kernel: [TTM] Zone  kernel: Available graphics
memory: 2027544 kiB.
Mar 21 00:57:38 localhost kernel: [TTM] Initializing pool allocator.
Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of VRAM memory ready
Mar 21 00:57:38 localhost kernel: [drm] radeon: 512M of GTT memory ready.
Mar 21 00:57:38 localhost kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Mar 21 00:57:38 localhost kernel: [drm] Driver supports precise vblank
timestamp query.
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: irq 49 for MSI/MSI-X
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: radeon: using MSI.
Mar 21 00:57:38 localhost kernel: [drm] radeon: irq initialized.
Mar 21 00:57:38 localhost kernel: [drm] GART: num cpu pages 131072, num gpu
pages 131072
Mar 21 00:57:38 localhost kernel: [drm] Loading RV635 Microcode
Mar 21 00:57:38 localhost kernel: radeon :01:00.0: WB enabled
Mar 21 00:57:38 localhost kernel: [drm] ring test succeeded in 1 usecs
Mar 21 00:57:38 localhost kernel: [drm] radeon: ib pool ready.
Mar 21 00:57:38 localhost kernel: [drm] ib test succeeded in 0 usecs
Mar 21 00:57:38 localhost kernel: [drm] Enabling audio support
Mar 21 00:57:38 localhost kernel: HDMI hot plug event: Pin=3 Presence_Detect=0
ELD_Valid=0

If there is any more info I can provide, please ask.

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

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Michel Dänzer]

On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote: 
> 
> 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> but figured it would make first sense to get your guys input before heading 
> that route.

It's worse than unsightly: It breaks TTM on PPC. See
arch/powerpc/include/asm/dma-mapping.h: get_dma_ops() returns NULL if
NULL is passed in for the device, and most of its callers BUG in that
case. The exception being dma_supported(), so a possible solution might
be to use that for checking if dma_alloc_coherent can be used.

Dave, please prevent this change from entering mainline before there's a
solution for this.


-- 
Earthling Michel D?nzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

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

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

--- Comment #1 from Alex Deucher  2011-03-21 07:23:42 PDT 
---
Can you bisect?

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

[Bug 35502] Regression: black screen with Radeon KMS in 2.6.38 (2.6.37.4 worked fine)

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

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

--- Comment #2 from John Lindgren  2011-03-21 
07:42:40 PDT ---
I will see if I can find the time.  Probably not before this weekend.

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

Future desktop on dumb frame buffers?

[Jesse Barnes]

On Sat, 19 Mar 2011 12:20:24 +0100
Geert Uytterhoeven  wrote:

> As noone responded to my question in
> http://www.spinics.net/lists/dri-devel/msg08851.html
> (yes, it was a bit hidden in a thread), I'm asking it here again (and
> also on the Wayland
> mailing list).
> 
> Basically I'm still puzzled about this KMS thing. If the name "Kernel
> Mode Setting"
> covers it, then how does it compare to plain fbdev? Just additional frame 
> buffer
> memory management?
> Also, some people may remember we did have kernel messages (e.g. oops, panic)
> on graphical consoles with fbdev, until people started not liking them
> showing up
> on their X desktops...

We support panic these days as well, but people still don't like seeing
them. :)

The DRM KMS APIs provide everything fbdev provides, plus memory
management, a way to expose acceleration (via GEM or TTM), and a way to
manage multiple outputs reasonably.

> Furthermore, everybody states that "future desktop" (that's
> http://wayland.freedesktop.org/)
> will require KMS drivers.
> How do/will we handle this on dumb frame buffers? It's not like we can't do
> "advanced" things like compositing using the CPU. Transparency may stretch
> it a bit on lower end CPUs, but you don't always need that.

There's nothing in DRM that precludes doing simple fbdev-like drivers
as well, though for many embedded uses I wouldn't expect it to provide
a whole lot of benefit.

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 34088] Update autotools configuration

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

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

Javier Jard?n  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Javier Jard?n  2011-03-21 11:19:43 
PDT ---
Committed in commit
http://cgit.freedesktop.org/mesa/drm/commit/?id=fd3ed34a2070fca3804baf54ece40d0bc2666226Commited
in commit

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

Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 19:19:43 +
timofonic timofonic  wrote:
> So if KMS is so cool and provides many advantages over fbdev and
> such... Why isn't more widely used intead of still relying on fbdev?
> Why still using fbdev emulation (that is partial and somewhat broken,
> it seems) instead using KMS directly?

Used by what?  All three major GPU device classes have KMS support
(Intel, ATI, and nVidia).  If you want it for a particular device, you
can always port it over.

As for fbdev emulation, what's still using it?  There's nothing
stopping projects from converting over; X and Wayland can already
handle KMS APIs just fine.

> I know the graphic driver situation is quite bad on Linux, especially
> on the embedded world. Fbdev seems is still quite used there by binary
> blob drivers.

Probably for a couple of reasons:
  1) inertia: fbdev has been around a lot longer, and provides most of
  what embedded devices need anyway
  2) feature set: why bother doing a full KMS driver if you're not
  going to use any of the additional features it would provide (output
  management, memory management, execution management)

Jesse

Future desktop on dumb frame buffers?

[timofonic timofonic]

Hello.

I have some rants and questions about fbdev, KMS and graphics stuff to
Linux. I'm just a mere user and occasional system administrator (and
going to start computer programming soon), but I hope to be able to
understand this situation better.

So if KMS is so cool and provides many advantages over fbdev and
such... Why isn't more widely used intead of still relying on fbdev?
Why still using fbdev emulation (that is partial and somewhat broken,
it seems) instead using KMS directly?

I know the graphic driver situation is quite bad on Linux, especially
on the embedded world. Fbdev seems is still quite used there by binary
blob drivers.

I was a fan of projects like DirectFB and such, but it seems they lack
the manpower or fuel to keep the project relevant. Maybe Wayland can
be their substitute and even have a broader usage too.

I hope KMS gets stronger and the graphic drivers get more into the
open source world (instead violating GPL and doing an attitude I think
should be illegal), that news about open source PowerVR SGX drivers
seems very positive (and surprising, because Imagination Technologies
seems quite against FOSS).

I hope all this gets to suck a bit less. Linux graphics stack
foundation based on KMS, TTM/GEM, advanced hardware accelerated video
decoding of most formats (by using OpenCL plus FFMpeg/LibAV, for
example), Gallium3D and full OpenGL 4.x support could make me very
happy as user and future developer...

Sadly, stuff like S3TC and such makes me very sad. I hope it gets
resolved sucessfully, patents are the nightmare of the technology...


Regards.

On Mon, Mar 21, 2011 at 6:00 PM, Jesse Barnes  
wrote:
> On Sat, 19 Mar 2011 12:20:24 +0100
> Geert Uytterhoeven  wrote:
>
>> As noone responded to my question in
>> http://www.spinics.net/lists/dri-devel/msg08851.html
>> (yes, it was a bit hidden in a thread), I'm asking it here again (and
>> also on the Wayland
>> mailing list).
>>
>> Basically I'm still puzzled about this KMS thing. If the name "Kernel
>> Mode Setting"
>> covers it, then how does it compare to plain fbdev? Just additional frame 
>> buffer
>> memory management?
>> Also, some people may remember we did have kernel messages (e.g. oops, panic)
>> on graphical consoles with fbdev, until people started not liking them
>> showing up
>> on their X desktops...
>
> We support panic these days as well, but people still don't like seeing
> them. :)
>
> The DRM KMS APIs provide everything fbdev provides, plus memory
> management, a way to expose acceleration (via GEM or TTM), and a way to
> manage multiple outputs reasonably.
>
>> Furthermore, everybody states that "future desktop" (that's
>> http://wayland.freedesktop.org/)
>> will require KMS drivers.
>> How do/will we handle this on dumb frame buffers? It's not like we can't do
>> "advanced" things like compositing using the CPU. Transparency may stretch
>> it a bit on lower end CPUs, but you don't always need that.
>
> There's nothing in DRM that precludes doing simple fbdev-like drivers
> as well, though for many embedded uses I wouldn't expect it to provide
> a whole lot of benefit.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>

Future desktop on dumb frame buffers?

[Corbin Simpson]

On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes  
wrote:
> On Mon, 21 Mar 2011 19:19:43 +
> timofonic timofonic  wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? ?All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). ?If you want it for a particular device, you
> can always port it over.
>
> As for fbdev emulation, what's still using it? ?There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.
>
>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
> ?1) inertia: fbdev has been around a lot longer, and provides most of
> ?what embedded devices need anyway
> ?2) feature set: why bother doing a full KMS driver if you're not
> ?going to use any of the additional features it would provide (output
> ?management, memory management, execution management)

Related: We are still missing basic userspace tools (kmsset, e.g.),
some kind of direct KMS console (kmscon would work, if it existed),
and an xf86-video-modesetting which compiles and works (this is
actually possible now, with some patches that landed in 2.6.38 for
generic KMS access.)

This is important to me, as the various old drivers I've been hacking
on won't be accepted upstream without some sort of userspace which can
work with them. One of the big goals of KMS was a generic
userspace-facing API, like FB, but without the suck.

~ C.

-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson

Future desktop on dumb frame buffers?

[Geert Uytterhoeven]

On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  wrote:
> On Mon, 21 Mar 2011 19:19:43 +
> timofonic timofonic  wrote:
>> So if KMS is so cool and provides many advantages over fbdev and
>> such... Why isn't more widely used intead of still relying on fbdev?
>> Why still using fbdev emulation (that is partial and somewhat broken,
>> it seems) instead using KMS directly?
>
> Used by what? ?All three major GPU device classes have KMS support
> (Intel, ATI, and nVidia). ?If you want it for a particular device, you
> can always port it over.

The three major GPU device classes on PC...

> As for fbdev emulation, what's still using it? ?There's nothing
> stopping projects from converting over; X and Wayland can already
> handle KMS APIs just fine.

Can Wayland handle fbdev APIs ...

>> I know the graphic driver situation is quite bad on Linux, especially
>> on the embedded world. Fbdev seems is still quite used there by binary
>> blob drivers.
>
> Probably for a couple of reasons:
> ?1) inertia: fbdev has been around a lot longer, and provides most of
> ?what embedded devices need anyway
> ?2) feature set: why bother doing a full KMS driver if you're not
> ?going to use any of the additional features it would provide (output
> ?management, memory management, execution management)

... if no additional features of KMS are needed?

Gr{oetje,eeting}s,

? ? ? ? ? ? ? ? ? ? ? ? Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds

Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 20:50:20 +0100
Geert Uytterhoeven  wrote:

> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  
> wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> > timofonic timofonic  wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what? ?All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia). ?If you want it for a particular device, you
> > can always port it over.
> 
> The three major GPU device classes on PC...

Yes, good point. :)

> > As for fbdev emulation, what's still using it? ?There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> 
> Can Wayland handle fbdev APIs ...

Yes.  Fundamentally, the Wayland protocol just assumes a way to share
buffers between processes.  For the software raster version of the Qt
port, Kristian created a shmem interface for doing that to allow the
results of CPU rendering to be passed around without copying.  On an
embedded device that would be one way to go.

-- 
Jesse Barnes, Intel Open Source Technology Center

Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 12:34:38 -0700
Corbin Simpson  wrote:
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)

Yeah, we used to call that drmcon, and it's still a big open.  I think
there are some projects that sit on top of fbdev and provide a good
text console with fancy character and input support, but I don't know
if any of them have been ported to KMS to handle multiple outputs or
with an aim toward integrating into a distro as a VT replacement.

kmsset or something would be pretty easy to do; the modetest program in
the drm repo would be a good starting point for that.  One limitation
there is handling fbcon, which makes reallocation of the framebuffer
somewhat difficult.

IIRC plymouth or whatever Fedora is using these days uses the KMS APIs
though...

-- 
Jesse Barnes, Intel Open Source Technology Center

Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 3:50 PM, Geert Uytterhoeven
 wrote:
> On Mon, Mar 21, 2011 at 20:25, Jesse Barnes  
> wrote:
>> On Mon, 21 Mar 2011 19:19:43 +
>> timofonic timofonic  wrote:
>>> So if KMS is so cool and provides many advantages over fbdev and
>>> such... Why isn't more widely used intead of still relying on fbdev?
>>> Why still using fbdev emulation (that is partial and somewhat broken,
>>> it seems) instead using KMS directly?
>>
>> Used by what? ?All three major GPU device classes have KMS support
>> (Intel, ATI, and nVidia). ?If you want it for a particular device, you
>> can always port it over.
>
> The three major GPU device classes on PC...

Sadly it gets worse.  A lot of the SoC vendors are adding an fbdev
emulation layer on top of v4l rather than using fbdev directly or
using KMS and v4l has grown it's own edid, hdmi, and cec handling.

Alex

>
>> As for fbdev emulation, what's still using it? ?There's nothing
>> stopping projects from converting over; X and Wayland can already
>> handle KMS APIs just fine.
>
> Can Wayland handle fbdev APIs ...
>
>>> I know the graphic driver situation is quite bad on Linux, especially
>>> on the embedded world. Fbdev seems is still quite used there by binary
>>> blob drivers.
>>
>> Probably for a couple of reasons:
>> ?1) inertia: fbdev has been around a lot longer, and provides most of
>> ?what embedded devices need anyway
>> ?2) feature set: why bother doing a full KMS driver if you're not
>> ?going to use any of the additional features it would provide (output
>> ?management, memory management, execution management)
>
> ... if no additional features of KMS are needed?
>
> Gr{oetje,eeting}s,
>
> ? ? ? ? ? ? ? ? ? ? ? ? Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 
> linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Future desktop on dumb frame buffers?

[Alan Cox]

>   1) inertia: fbdev has been around a lot longer, and provides most of
>   what embedded devices need anyway
>   2) feature set: why bother doing a full KMS driver if you're not
>   going to use any of the additional features it would provide (output
>   management, memory management, execution management)

3) its got documentation

Future desktop on dumb frame buffers?

[Ondrej Zary]

On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes  
wrote:
> > On Mon, 21 Mar 2011 19:19:43 +
> >
> > timofonic timofonic  wrote:
> >> So if KMS is so cool and provides many advantages over fbdev and
> >> such... Why isn't more widely used intead of still relying on fbdev?
> >> Why still using fbdev emulation (that is partial and somewhat broken,
> >> it seems) instead using KMS directly?
> >
> > Used by what? ?All three major GPU device classes have KMS support
> > (Intel, ATI, and nVidia). ?If you want it for a particular device, you
> > can always port it over.
> >
> > As for fbdev emulation, what's still using it? ?There's nothing
> > stopping projects from converting over; X and Wayland can already
> > handle KMS APIs just fine.
> >
> >> I know the graphic driver situation is quite bad on Linux, especially
> >> on the embedded world. Fbdev seems is still quite used there by binary
> >> blob drivers.
> >
> > Probably for a couple of reasons:
> > ?1) inertia: fbdev has been around a lot longer, and provides most of
> > ?what embedded devices need anyway
> > ?2) feature set: why bother doing a full KMS driver if you're not
> > ?going to use any of the additional features it would provide (output
> > ?management, memory management, execution management)
>
> Related: We are still missing basic userspace tools (kmsset, e.g.),
> some kind of direct KMS console (kmscon would work, if it existed),
> and an xf86-video-modesetting which compiles and works (this is
> actually possible now, with some patches that landed in 2.6.38 for
> generic KMS access.)

This looks interesting. If existing *fb drivers could be easily converted to 
KMS (including 2D acceleration) and then used in X with a common driver, it 
would be great. Let's say, convert cyber2000fb driver to KMS and use it in X 
with 2D acceleration.

> This is important to me, as the various old drivers I've been hacking
> on won't be accepted upstream without some sort of userspace which can
> work with them. One of the big goals of KMS was a generic
> userspace-facing API, like FB, but without the suck.


-- 
Ondrej Zary

Future desktop on dumb frame buffers?

[Jesse Barnes]

On Mon, 21 Mar 2011 21:20:08 +
Alan Cox  wrote:

> >   1) inertia: fbdev has been around a lot longer, and provides most of
> >   what embedded devices need anyway
> >   2) feature set: why bother doing a full KMS driver if you're not
> >   going to use any of the additional features it would provide (output
> >   management, memory management, execution management)
> 
> 3) its got documentation

Jeez, some people want it all.

You looking for docs for the ioctls and such?

-- 
Jesse Barnes, Intel Open Source Technology Center

Future desktop on dumb frame buffers?

[Matt Turner]

On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox  wrote:
>> ? 1) inertia: fbdev has been around a lot longer, and provides most of
>> ? what embedded devices need anyway
>> ? 2) feature set: why bother doing a full KMS driver if you're not
>> ? going to use any of the additional features it would provide (output
>> ? management, memory management, execution management)
>
> 3) its got documentation

My summer of code project's purpose was to create something of a
tutorial for writing a KMS driver. The code, split out into something
like 15 step-by-step patches, and accompanying documentation are
available from Google's website.

http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz

My repository (doesn't include the documentation) is available here:
http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary

There's a 'rebased' branch that contains API changes required for the
code to work with 2.6.37~.

It's nothing fantastic, but I've had a number of people tell me that
it was useful for them.

Thanks,
Matt

Future desktop on dumb frame buffers?

[Alex Deucher]

On Mon, Mar 21, 2011 at 5:13 PM, Ondrej Zary  
wrote:
> On Monday 21 March 2011 20:34:38 Corbin Simpson wrote:
>> On Mon, Mar 21, 2011 at 12:25 PM, Jesse Barnes 
> wrote:
>> > On Mon, 21 Mar 2011 19:19:43 +
>> >
>> > timofonic timofonic  wrote:
>> >> So if KMS is so cool and provides many advantages over fbdev and
>> >> such... Why isn't more widely used intead of still relying on fbdev?
>> >> Why still using fbdev emulation (that is partial and somewhat broken,
>> >> it seems) instead using KMS directly?
>> >
>> > Used by what? ?All three major GPU device classes have KMS support
>> > (Intel, ATI, and nVidia). ?If you want it for a particular device, you
>> > can always port it over.
>> >
>> > As for fbdev emulation, what's still using it? ?There's nothing
>> > stopping projects from converting over; X and Wayland can already
>> > handle KMS APIs just fine.
>> >
>> >> I know the graphic driver situation is quite bad on Linux, especially
>> >> on the embedded world. Fbdev seems is still quite used there by binary
>> >> blob drivers.
>> >
>> > Probably for a couple of reasons:
>> > ?1) inertia: fbdev has been around a lot longer, and provides most of
>> > ?what embedded devices need anyway
>> > ?2) feature set: why bother doing a full KMS driver if you're not
>> > ?going to use any of the additional features it would provide (output
>> > ?management, memory management, execution management)
>>
>> Related: We are still missing basic userspace tools (kmsset, e.g.),
>> some kind of direct KMS console (kmscon would work, if it existed),
>> and an xf86-video-modesetting which compiles and works (this is
>> actually possible now, with some patches that landed in 2.6.38 for
>> generic KMS access.)
>
> This looks interesting. If existing *fb drivers could be easily converted to
> KMS (including 2D acceleration) and then used in X with a common driver, it
> would be great. Let's say, convert cyber2000fb driver to KMS and use it in X
> with 2D acceleration.

You'd need to update the existing DDX to work with KMS.  Generally you
need some sort of userspace driver to allocate the buffers, deal with
acceleration alignment, build the acceleration command buffers, and
interface with X.

Alex

>
>> This is important to me, as the various old drivers I've been hacking
>> on won't be accepted upstream without some sort of userspace which can
>> work with them. One of the big goals of KMS was a generic
>> userspace-facing API, like FB, but without the suck.
>
>
> --
> Ondrej Zary
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

OT: sending patches to the list (was: [PATCH] kernel/drm: vblank wait on crtc > 1)

[Paul Menzel]

Am Sonntag, den 20.03.2011, 18:47 -0500 schrieb Ilija Hadzic:
> sorry about that, I use pine and thought that's as plain as it gets. I 
> guess next time I'll try just 'mail' from command line.

Or `git send-email`?.


Thanks,

Paul


? manual: `git help send-email`
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110321/9313c39c/attachment.pgp>

[RFC PATCH v2] Utilize the PCI API in the TTM framework.

[Konrad Rzeszutek Wilk]

On Mon, Mar 21, 2011 at 02:11:07PM +0100, Michel D?nzer wrote:
> On Fre, 2011-01-07 at 12:11 -0500, Konrad Rzeszutek Wilk wrote: 
> > 
> > 1) The 'NULL' when doing dma_alloc_coherent is unsightly. I was toying
> > with modifying the TTM API to pass in 'struct device' or 'struct pci_device'
> > but figured it would make first sense to get your guys input before heading 
> > that route.
> 
> It's worse than unsightly: It breaks TTM on PPC. See
> arch/powerpc/include/asm/dma-mapping.h: get_dma_ops() returns NULL if
> NULL is passed in for the device, and most of its callers BUG in that
> case. The exception being dma_supported(), so a possible solution might
> be to use that for checking if dma_alloc_coherent can be used.
> 
> Dave, please prevent this change from entering mainline before there's a
> solution for this.

We do have a fix for it: 

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
devel/ttm.pci-api.v5

Can you tell me if that works for you?

[Bug 35531] New: Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

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

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

   Summary: Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel
blows up
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
   URL: https://bugs.gentoo.org/show_bug.cgi?id=349247
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: chris2k01 at hotmail.com


Created an attachment (id=44703)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44703)
dmesg output from a successful attempt

When booting up Xorg server 1.9.2 with xf86-video-ati-6.14.0 and kernel
2.6.36-gentoo-r5 (distro-patched kernel, but the same problem doesn't appear in
2.6.35-g-r12), as soon as X starts, my monitor goes into DPMS powersave and I
get backtraces in dmesg.

A Gentoo developer suggested booting with kernel command-line parameter
"radeon.agpmode=-1". This didn't help.

I've attached dmesg output from a successful startup with 2.6.35, and will
attach dmesg output from failed startups with and without agpmode=-1
momentarily (looks like only one file can be attached at bug creation time).

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

[Bug 35531] Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

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

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

--- Comment #1 from Christopher Head  2011-03-21 
21:26:26 PDT ---
Created an attachment (id=44704)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44704)
dmesg output from a failed attempt

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

[Bug 35531] Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

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

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

--- Comment #2 from Christopher Head  2011-03-21 
21:26:41 PDT ---
Created an attachment (id=44705)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=44705)
dmesg output with radeon.agpmode=-1

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

[Bug 35531] Kernel 2.6.36 series, xf86-video-ati 6.14.0 kernel blows up

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

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

--- Comment #3 from Dave Airlie  2011-03-21 
21:42:27 PDT ---
that kernel doesn't have KMS enabled which is probably not what you want.

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