http://bugs.freedesktop.org/show_bug.cgi?id=27009
--- Comment #1 from Rafał Miłecki 2010-03-10 23:44:58 PST
---
I performed "make realclean && make distclean" before every compilation.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving thi
http://bugs.freedesktop.org/show_bug.cgi?id=27009
Summary: [REGR] radeon_tex_copy.c:73: do_copy_texsubimage:
Assertion `rrb && rrb->bo' failed.
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Stat
Dear Dave and others:
I seem to hit a sudden regression in 2.6.34-rc1: the modeset fails.
On this box it also means, no way to start X, which is unfortunate.
Here's a quote from bad dmesg (truncated front and back for brievity):
Linux agpgart interface v0.103
agpgart-intel :00:00.0: Intel HD
On Thu, Mar 11, 2010 at 02:22:14AM +, James Simmons wrote:
>
> > > > There are other drivers that support multihead already (matroxfb, any
> > > > other?) and have their own driver-specific inteface.
> > >
> > > Each crtc is treated as a seperate fbdev device. I don't recall any
> > > specia
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons wrote:
>
> Okay all the discussion about multiple display brings me to why I'm doing
> this. I'm attempting to revive the linux console project. I'm in a
> position to again work on this project. About 4 years ago the eproject
> managed to get multi-s
Okay all the discussion about multiple display brings me to why I'm doing
this. I'm attempting to revive the linux console project. I'm in a
position to again work on this project. About 4 years ago the eproject
managed to get multi-seat working. My goal is to get there again. My first
goal is
> > Yuck. See my other post about what fbdev really means in its historical
> > context. The struct fb_info really maps better to drm_crtc than to
> > drm_framebuffer. In fact take the case of the matrox fbdev driver. It
> > creates two framebuffer devices even tho it used one static framebuffer.
> > I don't think the CRTC=fb_info makes much sense if the main use
> > case is fbcon. fbcon will use a single fb device and so you can't see
> > the console on multiple heads anyway which makes the whole thing
> > somewhat pointless. And if you're trying to do something more complex
> > you will
> > > There are other drivers that support multihead already (matroxfb, any
> > > other?) and have their own driver-specific inteface.
> >
> > Each crtc is treated as a seperate fbdev device. I don't recall any
> > special ioctls. Maybe for mirroring which was never standardized.
>
> matroxfb d
Thanks to Jean for helping me with the i2c stuff. I've attached
Jean's bit algo patch as my radeon patch depends on it. I'm not sure
how we want to get that one upstream (either via drm or i2c).
Previously, the radeon drm registered i2c buses using the radeon algo
which would use either the hw i2
>From b2757f48c0c45ff08934d125b913777b8adaee0b Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 10 Mar 2010 18:33:03 -0500
Subject: [PATCH] drm/radeon/kms: fix pal tv-out support on legacy IGP chips
Based on ddx patch by Andrzej Hajda.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/rade
On Thu, 11 Mar 2010 00:21:13 +0200, Pauli Nieminen wrote:
> On Wed, Mar 10, 2010 at 10:44 PM, Julien Cristau wrote:
> > Should this really get installed? I'm not sure this should be public
> > libdrm interface.
> >
> > Cheers,
> > Julien
> >
>
> Intel had it installed.
My bad, change it to noi
On Wed, Mar 10, 2010 at 10:44 PM, Julien Cristau wrote:
>> On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen wrote:
>> > intel_atomic.h includes very usefull atomic operations for
>> > lock free parrallel access of variables. Moving these to
>> > core libdrm for code sharing with radeon.
>> >
>> >
http://bugs.freedesktop.org/show_bug.cgi?id=23532
Maciej Cencora changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Wednesday 10 March 2010, Matthew Garrett wrote:
> As far as the ACPI video driver goes, acpi_get_physical_pci_device()
> will give you something to work with.
Hmm. Did you mean acpi_get_physical_device()?
Which acpi_device should I call that for?
> For the console-switching case, I think th
On Wed, Mar 10, 2010 at 06:11:29PM +, James Simmons wrote:
>
> > I don't think so. There is another driver which does this -
> > vesa/uvesa. For these it is not possible to change the resolution from
> > fbdev, it just provides some framebuffer on top of which fb
> > applications or fbcons run
On Wed, Mar 10, 2010 at 1:47 PM, James Simmons wrote:
>
>> >> Yuck. See my other post about what fbdev really means in its historical
>> >> context. The struct fb_info really maps better to drm_crtc than to
>> >> drm_framebuffer. In fact take the case of the matrox fbdev driver. It
>> >> creates t
http://bugs.freedesktop.org/show_bug.cgi?id=26997
Summary: r600: broken mipmap generation
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
> >> Yuck. See my other post about what fbdev really means in its historical
> >> context. The struct fb_info really maps better to drm_crtc than to
> >> drm_framebuffer. In fact take the case of the matrox fbdev driver. It
> >> creates two framebuffer devices even tho it used one static framebuff
bo->referenced_in_cs is checked if bo is already in cs. Adding and removing
reference in bo is done with atomic operations to allow parallel access to a
bo from multiple contexts.
cs->id generation code quarentees there is not duplicated ids which limits
number of cs->ids to 32. If there is more c
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
V2: Fix remaining references to intel_atomic.h and libdrm-intel.
Signed-off-by: Pauli Nieminen
---
Makefile.am |2 +-
config
2010/3/10 Michel Dänzer :
> On Wed, 2010-03-10 at 18:20 +0200, Pauli Nieminen wrote:
>> Bit has table will be first checked from BO if we can quarentee this BO is
>> not
>> in this cs already.
>>
>> To quarentee that there is no other cs with same id number of CS that can
>> have
>> id is limited
On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen wrote:
> intel_atomic.h includes very usefull atomic operations for
> lock free parrallel access of variables. Moving these to
> core libdrm for code sharing with radeon.
>
> Signed-off-by: Pauli Nieminen
> ---
> Makefile.am | 2 +-
>
> I don't think so. There is another driver which does this -
> vesa/uvesa. For these it is not possible to change the resolution from
> fbdev, it just provides some framebuffer on top of which fb
> applications or fbcons run.
Only because that is the only way to do it. The other options was to h
On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher wrote:
> On Wed, Mar 10, 2010 at 12:42 PM, James Simmons
> wrote:
>>
>>> >> At the moment the problem with fbset is what to do with it in the
>>> >> dual head case. Currently we create an fb console that is lowest
>>> >> common size of the two heads
On Wed, Mar 10, 2010 at 12:42 PM, James Simmons wrote:
>
>> >> At the moment the problem with fbset is what to do with it in the
>> >> dual head case. Currently we create an fb console that is lowest
>> >> common size of the two heads and set native modes on both,
>> >
>> > Does that mean that fbs
> My main problem with calling the drm underneath the fbdev is it
> seems like a layering violation. Then again some of code in the kernel
> is also contributing to this violation. I'd really like to make fbdev more
> like an in-kernel version of what X driver have to do, and leave all the
> initi
> >> At the moment the problem with fbset is what to do with it in the
> >> dual head case. Currently we create an fb console that is lowest
> >> common size of the two heads and set native modes on both,
> >
> > Does that mean that fbset is supposed to work (set resolution) on drmfb?
>
> No we'v
> On 21 November 2009 05:27, Dave Airlie wrote:
>
> > At the moment the problem with fbset is what to do with it in the
> > dual head case. Currently we create an fb console that is lowest
> > common size of the two heads and set native modes on both,
>
> Does that mean that fbset is supposed t
On Wed, 2010-03-10 at 18:20 +0200, Pauli Nieminen wrote:
> Bit has table will be first checked from BO if we can quarentee this BO is not
> in this cs already.
>
> To quarentee that there is no other cs with same id number of CS that can have
> id is limited to 32. Adding and remocing reference i
intel_atomic.h includes very usefull atomic operations for
lock free parrallel access of variables. Moving these to
core libdrm for code sharing with radeon.
Signed-off-by: Pauli Nieminen
---
Makefile.am |2 +-
configure.ac |2 +-
intel/intel_atomic.h | 56 +---
Bit has table will be first checked from BO if we can quarentee this BO is not
in this cs already.
To quarentee that there is no other cs with same id number of CS that can have
id is limited to 32. Adding and remocing reference in bo is done with atomic
operations to allow parallel access to a bo
> Would anyone have objections if these lists moved to freedesktop.org?
> The recent thread with Linus about the drm pull request highlights the
> post lag and non-subscriber aspect of the current lists, and that
> leaves aside sf.net's horrible mail archive interface and poor
> performance.
>
>
http://bugzilla.kernel.org/show_bug.cgi?id=15276
--- Comment #52 from Jérôme Glisse 2010-03-10
15:41:55 ---
I pushed a tree with a rework of GPU reset and GPU lockup detection, some user
indicate that this work better than the current code, please give it a try :
Full tree:
git://git.kerne
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Bartosz Brachaczek changed:
What|Removed |Added
Keywords||patch
--
Configure bugmail: htt
http://bugs.freedesktop.org/show_bug.cgi?id=26994
--- Comment #2 from Bartosz Brachaczek 2010-03-10
05:33:29 PST ---
Created an attachment (id=33920)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33920)
correct patch for this issue
--
Configure bugmail: http://bugs.freedesktop.org/
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Bartosz Brachaczek changed:
What|Removed |Added
CC||b.brachac...@gmail.com
On Fri, Feb 26, 2010 at 19:07:24 +0100, Julien Cristau wrote:
> Avoids conflicts with kernel headers.
>
> Signed-off-by: Julien Cristau
> ---
> This was suggested by Eric so distros can let the kernel install drm
> headers, but provide updated headers from libdrm so we can build new
> drivers re
On Sun, 07 Mar 2010 12:39:15 +0200
Maxim Levitsky wrote:
> On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
> > On Sun, 07 Mar 2010 00:24:24 +0200
> > Maxim Levitsky wrote:
> >
> > > On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
> > > > On Sat, 2010-03-06 at 22:35 +0100, Flo
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Summary: Openchrome r839 does not build. Changes required in
via_drm.h
Product: DRI
Version: unspecified
Platform: Other
OS/Version: Linux (All)
Status: NEW
On Wed, Mar 10, 2010 at 7:50 AM, Paul Mundt wrote:
> On Tue, Mar 09, 2010 at 10:08:28PM +0100, Rafael J. Wysocki wrote:
>> On Tuesday 09 March 2010, James Simmons wrote:
>> >
>> > > > > Second, in the KMS case, we'd be able to skip the kernel VT switch,
>> > > > > because
>> > > > > the KMS drive
On Tue, Mar 9, 2010 at 4:45 PM, Jerome Glisse wrote:
> This patch cleanup the fence code, it drops the timeout field of
> fence as the time to complete each IB is unpredictable and shouldn't
> be bound.
>
> The fence cleanup lead to GPU lockup detection improvement, this
> patch introduce a callba
with dri enabled, after un-hibernating machine
mouse cursor gets split into individual lines ,
and can be moved only in corner of the screen.
keyboard becomes unresponsive, one cannot switch to vt.
with dri disabled, un-hibernating is fine.
--
---
http://bugs.freedesktop.org/show_bug.cgi?id=26887
Marc changed:
What|Removed |Added
Severity|normal |critical
--- Comment #6 from Marc 2010-03-10
44 matches
Mail list logo
