On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
wrote:
> Hi,
>
> On drivers using drm_fb_helper's in fb_ops it is not possible to change
> video mode, because of different var->pixclock evaluation:
>
> int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
> struc
On Sat, Nov 21, 2009 at 6:48 AM, James Simmons wrote:
>
>
> On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
>
>> On 11/20/2009 10:01 PM, James Simmons wrote:
>> >
>> > > > > > Paulius Zaleckas wrote:
>> > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
>> > > > > > > change
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #10 from Ed Tomlinson 2009-11-20 16:48:13 PST ---
Just to confirm, reverting 286bf89e5a1fc931dbf523ded861b809859485e2 fixes the
corruption here.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
---
http://bugs.freedesktop.org/show_bug.cgi?id=25193
Ed Tomlinson changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTABUG
http://bugzilla.kernel.org/show_bug.cgi?id=13683
--- Comment #24 from Alex Deucher 2009-11-20 23:41:49
---
(In reply to comment #23)
> Still the same with latest git. Is it possible that the bios lies about the
> connectors ?
It's possible, but not likely. The bios claims you have local
Hello Thomas:
> I know this kernel module is made for VIAs own X.org driver and not
> openchrome but:
> 1. I don't think userspace should be able to easily trigger a kernel oops,
> and
> 2. Can't this new VIA Chrome9 DRM interface be made more compatible to the
>existing one? Ideally it wou
2009/11/19 Eric Anholt :
> On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote:
>> 2009/11/6 Kristian Høgsberg :
>> > Hi,
>> >
>> > This has come up a few time and it's something I think makes a lot of
>> > sense. Since all driver development (afaik) now happens in linux
>> > kernel tree, i
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #8 from Allen Walker 2009-11-20
13:15:56 PST ---
Created an attachment (id=31351)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31351)
ingame garbled
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=em
http://bugs.freedesktop.org/show_bug.cgi?id=21501
--- Comment #5 from rem11_1...@yahoo.fr 2009-11-20 13:02:23 PST ---
Tested with mesa branch master from now (after branch 7.7 was merged in) and
same error message :
scourge: radeon_texture.c:875: migrate_image_to_miptree: Assertion
`srclvl->
On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
> On 11/20/2009 10:01 PM, James Simmons wrote:
> >
> > > > > > Paulius Zaleckas wrote:
> > > > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
> > > > > > > change
> > > > > > > video mode, because of different var->pixclock ev
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #7 from Allen Walker 2009-11-20
12:09:22 PST ---
(In reply to comment #6)
> Please try my r300-blit branch.
Was half success, failed half. My problem is that I can only get indirect
rendering working and cannot compile 32bit lib
> > > > Paulius Zaleckas wrote:
> > > > > On drivers using drm_fb_helper's in fb_ops it is not possible to
> > > > > change
> > > > > video mode, because of different var->pixclock evaluation: ...
> > > >
> > > > patch:
> > > > http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.
On Fri, 20 Nov 2009 18:53:37 + (GMT)
James Simmons wrote:
>
> > Paulius Zaleckas wrote:
> > > On drivers using drm_fb_helper's in fb_ops it is not possible to change
> > > video mode, because of different var->pixclock evaluation: ...
> >
> > patch:
> > http://www.mail-archive.com/dri-devel
> Paulius Zaleckas wrote:
> > On drivers using drm_fb_helper's in fb_ops it is not possible to change
> > video mode, because of different var->pixclock evaluation: ...
>
> patch:
> http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
Those patches will enable fbdev apps to
On Fri, Nov 20, 2009 at 11:47:22AM -0500, Alex Deucher wrote:
> On Fri, Nov 20, 2009 at 8:29 AM, Jerome Glisse wrote:
> > We force the crtc & cursor bo to be in the first 64M, this
> > will help on legacy modesetting hw where the offset of
> > scanout buffer and cursor are relative to a base addre
Paulius Zaleckas wrote:
> On drivers using drm_fb_helper's in fb_ops it is not possible to change
> video mode, because of different var->pixclock evaluation: ...
patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
> P.S. check CLCOK spelling :)
This patch got lost d
On Fri, Nov 20, 2009 at 8:29 AM, Jerome Glisse wrote:
> We force the crtc & cursor bo to be in the first 64M, this
> will help on legacy modesetting hw where the offset of
> scanout buffer and cursor are relative to a base address.
This limitation only applies to pre-avivo (r1xx-r4xx) chips, ther
http://bugs.freedesktop.org/show_bug.cgi?id=25193
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=25198
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Fri, Nov 20, 2009 at 5:45 AM, Viktor Malyarchuk wrote:
> Dear David,
>
> thank you and all the developers involved for your outstanding DRM/KMS work.
>
> There is a problem that was introduced in 2.6.32-rc6-git5.
>
> SUMMARY
> any mode switch on MacBookPro2,2 is delayed by 130 seconds of black
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #6 from Maciej Cencora 2009-11-20 08:06:21
PST ---
Please try my r300-blit branch.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assi
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #8 from Florian Scandella 2009-11-20 07:54:18
PST ---
hmm.. thats strange, a new clone fixed the problems ... didn't get any changes
with pull.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
---
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #7 from Alex Deucher 2009-11-20 07:41:22 PST ---
(In reply to comment #5)
> same thing here ...
>
> ~ $ LIBGL_DEBUG=verbose glxgears
> libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so
> libGL: OpenDriver: trying /usr/lib6
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #6 from Alex Deucher 2009-11-20 07:40:29 PST ---
(In reply to comment #2)
> To avoid this problem current libdrm should be tagged as 2.4.16 and mesa
> should
> require libdrm_radeon >= 2.4.16.
>
That will be done once KMS is of
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #5 from Allen Walker 2009-11-20
07:10:40 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > samples %symbol name
> > 633992 98.0560 radeon_ptr_4byte
> > 11532 1.7836 radeonReadRGBASpan_ARGB
>
>
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #4 from Roland Scheidegger
2009-11-20 06:51:38 PST ---
(In reply to comment #3)
> samples %symbol name
> 633992 98.0560 radeon_ptr_4byte
> 11532 1.7836 radeonReadRGBASpan_ARGB
This is a software fallback - m
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #5 from Florian Scandella 2009-11-20 06:42:33
PST ---
same thing here ...
~ $ LIBGL_DEBUG=verbose glxgears
libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so
libGL error
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
V2: A fix were missing in the first version, only update
node->private if we are actualy dealing with a node.
Signed-off-by: Jerome Glisse
---
drivers/g
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #4 from Fabio 2009-11-20 06:15:57 PST ---
Could you try running:
LIBGL_DEBUG=verbose glxgears
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You ar
http://bugs.freedesktop.org/show_bug.cgi?id=22851
Fabio changed:
What|Removed |Added
Summary|radeon_lock.c:65: |[bisected] radeon_lock.c:65:
|
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #3 from Allen Walker 2009-11-20
06:06:50 PST ---
better results:
$ opreport -l /usr/lib/xorg/modules/dri/r300_dri.so | head
Overflow stats not available
CPU: AMD64 processors, speed 1607.55 MHz (estimated)
Counted CPU_CLK_UNHAL
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #2 from Allen Walker 2009-11-20
05:59:50 PST ---
ok, got oprofile running and it shows me:
$ oprofile | head
Overflow stats not available
CPU: AMD64 processors, speed 1607.55 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycl
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c| 305 ++-
include/drm/ttm/ttm_bo_api.h|5 +
We force the crtc & cursor bo to be in the first 64M, this
will help on legacy modesetting hw where the offset of
scanout buffer and cursor are relative to a base address.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h |3 ++
drivers/gpu/drm/radeon/radeon_cursor
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var->pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
[...]
if (var->pixclock == -1 || !var->pixc
This patch series add ttm range validation function. Aim is to
include this in 2.6.33 so i have time to iron out issue, comments.
ttm:
I duplicated a bunch of ttm functions but now i think, best would
be to add range to all function and use free list if range cover
all the manager space. Doing so
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #1 from Allen Walker 2009-11-20
04:51:46 PST ---
Created an attachment (id=31341)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31341)
short xorg session with touhou 11 running
I compiled xorg-server-1.7.1.901 with -pg and
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #3 from Ed Tomlinson 2009-11-20 04:04:24 PST ---
This turns out not to be the case. As stated in the initial report libdrm is
from git. My log shows the correct api enabled:
>>> Emerging (1 of 1) x11-libs/libdrm- from x11
http://bugs.freedesktop.org/show_bug.cgi?id=25197
Maciej Cencora changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Maciej
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #4 from samit vats 2009-11-20 03:43:29 PST ---
Created an attachment (id=31340)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31340)
glxgears-log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
-
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #3 from samit vats 2009-11-20 03:42:55 PST ---
Created an attachment (id=31339)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31339)
lspci
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
---
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #2 from samit vats 2009-11-20 03:42:14 PST ---
Created an attachment (id=31338)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31338)
xorg.conf
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #1 from samit vats 2009-11-20 03:41:48 PST ---
Created an attachment (id=31337)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31337)
Xorg.log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
-
http://bugs.freedesktop.org/show_bug.cgi?id=25198
Summary: [R6XX] : System hard hangs on launching OpenGL
application
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: other
Status: NEW
Severity:
http://bugs.freedesktop.org/show_bug.cgi?id=25197
--- Comment #1 from Rafał Miłecki 2009-11-20 03:15:26 PST
---
Created an attachment (id=31335)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31335)
openarena.log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=em
http://bugs.freedesktop.org/show_bug.cgi?id=25197
Summary: [REGRESSION] openarena: vbo/vbo_exec_api.c:881:
vbo_exec_FlushVertices: Assertion `callDepth == 1'
failed.
Product: Mesa
Version: unspecified
Platform: Othe
http://bugs.freedesktop.org/show_bug.cgi?id=25179
--- Comment #2 from Fabio 2009-11-20 01:09:36 PST ---
> Does it work without that "fix" for the 7.6 branch?
No, with a clean clone of 7.7 branch it asserts in a similar way to bug #24131
(see below). Apparently the "Leaking dma buffer object
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #2 from Fabio 2009-11-20 00:59:13 PST ---
(In reply to comment #1)
> Sounds like you are building against an old version of libdrm_radeon. To
> update build libdrm configured with --enable-radeon-experimental-api
To avoid this p
http://bugzilla.kernel.org/show_bug.cgi?id=13683
--- Comment #23 from Jan Kreuzer 2009-11-20 08:37:49 ---
Still the same with latest git. Is it possible that the bios lies about the
connectors ? When i used the real old non-kms, non-xrandr radeon driver i had
to specify MonitorLayout LVDS,no
49 matches
Mail list logo