http://bugs.freedesktop.org/show_bug.cgi?id=26887
Marc marvi...@gmx.de changed:
What|Removed |Added
Severity|normal |critical
--- Comment #6 from
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.
--
On Tue, Mar 9, 2010 at 4:45 PM, Jerome Glisse jgli...@redhat.com 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
On Wed, Mar 10, 2010 at 7:50 AM, Paul Mundt let...@linux-sh.org 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 driver
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 Sun, 07 Mar 2010 12:39:15 +0200
Maxim Levitsky maximlevit...@gmail.com wrote:
On Sat, 2010-03-06 at 23:55 +0100, Florian Mickler wrote:
On Sun, 07 Mar 2010 00:24:24 +0200
Maxim Levitsky maximlevit...@gmail.com wrote:
On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote:
On
On Fri, Feb 26, 2010 at 19:07:24 +0100, Julien Cristau wrote:
Avoids conflicts with kernel headers.
Signed-off-by: Julien Cristau jcris...@debian.org
---
This was suggested by Eric so distros can let the kernel install drm
headers, but provide updated headers from libdrm so we can build
http://bugs.freedesktop.org/show_bug.cgi?id=26994
Bartosz Brachaczek b.brachac...@gmail.com changed:
What|Removed |Added
CC|
http://bugs.freedesktop.org/show_bug.cgi?id=26994
--- Comment #2 from Bartosz Brachaczek b.brachac...@gmail.com 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/show_bug.cgi?id=26994
Bartosz Brachaczek b.brachac...@gmail.com changed:
What|Removed |Added
Keywords||patch
--
http://bugzilla.kernel.org/show_bug.cgi?id=15276
--- Comment #52 from Jérôme Glisse gli...@freedesktop.org 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 :
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.
If
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
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 suok...@gmail.com
---
Makefile.am |2 +-
configure.ac |2 +-
intel/intel_atomic.h |
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 in bo
On 21 November 2009 05:27, Dave Airlie airl...@gmail.com 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
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've never hooked
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
initial
On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org 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
On Wed, Mar 10, 2010 at 1:05 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Mar 10, 2010 at 12:42 PM, James Simmons jsimm...@infradead.org
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
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 have
On Wed, Mar 10, 2010 at 11:20 AM, Pauli Nieminen suok...@gmail.com 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 suok...@gmail.com
---
2010/3/10 Michel Dänzer mic...@daenzer.net:
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
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 cs
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 suok...@gmail.com
---
Makefile.am
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.
What
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
On Wed, Mar 10, 2010 at 1:47 PM, James Simmons jsimm...@infradead.org 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
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 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 the
From b2757f48c0c45ff08934d125b913777b8adaee0b Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
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
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 does have a
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 be a lot
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.
What
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
On Thu, Mar 11, 2010 at 1:51 PM, James Simmons jsimm...@infradead.org 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
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
special ioctls. Maybe
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
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
http://bugs.freedesktop.org/show_bug.cgi?id=27009
--- Comment #1 from Rafał Miłecki zaj...@gmail.com 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
40 matches
Mail list logo
