http://bugs.freedesktop.org/show_bug.cgi?id=25355
Fabio changed:
What|Removed |Added
CC||david.ro...@mcgill.ca
--- Comment #4 from Fab
http://bugs.freedesktop.org/show_bug.cgi?id=25478
Fabio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Thu, Dec 10, 2009 at 02:01:11PM +1000, Dave Airlie wrote:
> On Thu, Dec 10, 2009 at 3:35 AM, Jerome Glisse wrote:
> > This patch add a function which check module argument to be
> > valid. On invalid argument it prints a warning and setback
> > the default value.
>
> This seems to screw up her
http://bugs.freedesktop.org/show_bug.cgi?id=23106
--- Comment #5 from Fabio 2009-12-10 01:09:54 PST ---
This could be a duplicate of bug #25505.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assig
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #4 from Adam K Kirchhoff 2009-12-10 01:59:29
PST ---
According to glxinfo and the Xorg log file, you have 3D acceleration working.
What happens when you try to enable compositing in KDE or gnome? Please attach
the output of 'x
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #5 from Antenore Gatta 2009-12-10 02:12:24
PST ---
Created an attachment (id=31923)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31923)
xdpyinfo
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #6 from Antenore Gatta 2009-12-10 02:13:44
PST ---
Thanks a lot Adam, really fast answer!!! Much appreciated.
This is the error message:
Failed to activate desktop effects using the given configuration options.
Settings will be
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #7 from Adam K Kirchhoff 2009-12-10 03:28:08
PST ---
Unless someone else here has any ideas, this sounds like something you should
take up with the KDE folks. 3D acceleration is enabled, compositing is enabled
in the X server,
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #8 from Antenore Gatta 2009-12-10 04:39:22
PST ---
(In reply to comment #7)
> Unless someone else here has any ideas, this sounds like something you should
> take up with the KDE folks. 3D acceleration is enabled, compositing is
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #9 from Adam K Kirchhoff 2009-12-10 04:50:27
PST ---
What happens if you bring up a terminal and run 'LIBGL_ALWAYS_INDIRECT=1 compiz
--replace ccp &'? Do you get any errors or does compiz start up properly?
--
Configure bugm
http://bugs.freedesktop.org/show_bug.cgi?id=2
--- Comment #10 from Antenore Gatta 2009-12-10 05:00:10
PST ---
(In reply to comment #9)
> What happens if you bring up a terminal and run 'LIBGL_ALWAYS_INDIRECT=1
> compiz
> --replace ccp &'? Do you get any errors or does compiz start up
http://bugs.freedesktop.org/show_bug.cgi?id=2
Alec Habig changed:
What|Removed |Added
CC||aha...@umn.edu
--- Comment #11 from Alec
http://bugs.freedesktop.org/show_bug.cgi?id=2
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=25544
--- Comment #1 from Roland Scheidegger
2009-12-10 07:23:35 PST ---
Created an attachment (id=31941)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31941)
possible fix
does this patch help?
As you suspect there are differences due to th
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index a835b6f..c62818f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.
On Thu, 10 Dec 2009, Dave Airlie wrote:
>
> The biggest missing feature [ ... ]
No, the biggest missing feature is that Fedora is _still_ shipping
Nouveau, and I'm _still_ not seeing Red Hat people actively trying to get
it merged into mainline.
What the _hell_ is going on?
On Tue, Dec 8, 2009 at 11:17 PM, Viktor Malyarchuk wrote:
> Hi Alex,
>
> patch did not change anything for me. Problem still there.
>
Can you try Dave's drm-radeon-testing or drm-radeon-next tree?
Specifically this patch:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;
Convert ttm_buffer_object_init to use struct ttm_placement and
rename to ttm_bo_init for consistency with function naming. This
allow to give more complex placement at buffer creation. For
instance you ask to allocate bo into vram first but if there is
not enough vram you can give system as a secon
Hi,
So here is a patch which convert bo_init to use struct ttm_placement
rather than flag. It allow the driver to give placement preference
on where to create a bo. Also allow to create a bo at specific range
which is i believe somethings nouveau would like to see :)
Aside from the change i renam
Now bo init use placement structure like bo validation does.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c | 39 +++
1 files changed, 9 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/r
On Thu, 2009-12-10 at 07:17 -0800, Linus Torvalds wrote:
>
> On Thu, 10 Dec 2009, Dave Airlie wrote:
> >
> > The biggest missing feature [ ... ]
>
> No, the biggest missing feature is that Fedora is _still_ shipping
> Nouveau, and I'm _still_ not seeing Red Hat people actively trying to get
>
On Thu, 10 Dec 2009, Xavier Bestel wrote:
>
> Last time they were asked that, they wanted to be free of changing their
> kernel/userspace interface before upstreaming.
I've heard all the excuses. If it isn't ready, they shouldn't ship it to
millions of people. And if it's ready, they should wo
I am not sure we want this patch, i have got mixed feeling about
it. It might be usefull in some strange use case where creation
will fail but future validation of the buffer might succeed.
I will try to upload it to fdo in order to keep it around in
case it might actualy prove helpfull in the futu
This patch allow object creation to fallback to system memory
if the proposed domains doesn't have room yet to accomodate
for the buffer. Will be usefull when creating big buffer on
small memory configuration when we need to evict first old
buffer (old buffer being possibly pinned).
Signed-off-by:
System memory type doesn't have a drm_mm manager associated to
it. This patch avoid trying to call drm_mm_debug on unitialized
drm_mm when printing debug info on the system memory manager.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 19 +--
1 files changed,
> Last time they were asked that, they wanted to be free of changing their
> kernel/userspace interface before upstreaming.
So put it in staging with a note to that effect. That'll also get it more
exposure and review.
Alan
On Thu, Dec 10, 2009 at 5:24 PM, Linus Torvalds
wrote:
>
>
> On Thu, 10 Dec 2009, Xavier Bestel wrote:
>>
>> Last time they were asked that, they wanted to be free of changing their
>> kernel/userspace interface before upstreaming.
>
> I've heard all the excuses. If it isn't ready, they shouldn't
On Thu, 10 Dec 2009, Maarten Maathuis wrote:
>
> You assume that Red Hat has full control over the project, which i
> don't think is the case. The reason it isn't in staging yet (as far as
> i know) is because of some questions over the copyright of some
> (essential) microcode. Either the quest
Hi Linus,
On Thu, 10 Dec 2009, Maarten Maathuis wrote:
>> You assume that Red Hat has full control over the project, which i
>> don't think is the case. The reason it isn't in staging yet (as far as
>> i know) is because of some questions over the copyright of some
>> (essential) microcode. Either
On Thu, 2009-12-10 at 10:42 -0800, Linus Torvalds wrote:
> The fact is, if there are license questions, then Fedora had better
> not be
> distributing the code either. And they clearly are.
This was the issue that prevented me from merging/shipping it with
FreeBSD 8.0. Without getting foundation
> The fact is, if there are license questions, then Fedora had better not be
> distributing the code either. And they clearly are.
Their choice, but it's not their project - they are just chosing to
import it.
> I've heard the "but it's hard to merge" excuse too - which I also know is
> bullshi
On Thu, 10 Dec 2009 10:42:46 -0800 (PST)
Linus Torvalds wrote:
> I _think_ that last one was meant as a joke. But it's damn hard to
> tell, because the ones that are apparently sincere are equally crazy.
> People just seem to make up total crap to make excuses for something
> that everybody knows
On Fri, Dec 11, 2009 at 4:42 AM, Linus Torvalds
wrote:
>
>
> On Thu, 10 Dec 2009, Maarten Maathuis wrote:
>>
>> You assume that Red Hat has full control over the project, which i
>> don't think is the case. The reason it isn't in staging yet (as far as
>> i know) is because of some questions over
On Thu, 10 Dec 2009 10:42:46 -0800 (PST)
Linus Torvalds wrote:
> On Thu, 10 Dec 2009, Maarten Maathuis wrote:
> >
> > You assume that Red Hat has full control over the project,
> > which i don't think is the case. The reason it isn't in staging
> > yet (as far as i know) is because of some quest
Jerome Glisse wrote:
> Hi,
>
> So here is a patch which convert bo_init to use struct ttm_placement
> rather than flag. It allow the driver to give placement preference
> on where to create a bo. Also allow to create a bo at specific range
> which is i believe somethings nouveau would like to see :
I'm trying to put together a highly optimized compute driver for the
company I work for and had to ask this question myself recently. From
what I know there's only one reason it hasn't gotten pushed, but that's
being worked on by someone at RH.
However to clear up some of the doubts about thi
On Thu, Dec 10, 2009 at 19:42, Linus Torvalds
wrote:
>
>
> On Thu, 10 Dec 2009, Maarten Maathuis wrote:
>>
>> You assume that Red Hat has full control over the project, which i
>> don't think is the case. The reason it isn't in staging yet (as far as
>> i know) is because of some questions over th
> If someone has time to take the nouveau patches and convert all the dubious
> pieces of code to firmware loader interface and set it up so the main code
> can be merged upstream and the firmware left to one side and someone
> else can possibly redistribute the firmware then it might happen q
Jakob Bornecrantz wrote:
> This patch series add the vmwgfx driver to the kernel tree inside
> the staging tree. I split the patch in two parts as the svga
> headers fail checkpatch quite hard. The svga* headers are shared
> between a lot of different components but I can understand if they
> get r
Jerome Glisse wrote:
> This patch series add printing of all informations necessary to
> understand why getting memory space fails. I have mixed feeling
> on letting this enabled by default or only enabling it with debug
> compile flags.
>
> Cheers,
> Jerome
>
>
Jerome,
This is Acked-By me, alth
Pekka Paalanen
> The fact is, if there are license questions, then Fedora had
> better not be distributing the code either. And they clearly are.
I've no idea how they pulled that, but I have not heard anyone
say that there are *no* legal issues at all.
> I've heard the "but it's hard to merg
On Thu, Dec 10, 2009 at 2:49 PM, Pekka Paalanen wrote:
> The big question is what we call ctxprogs: binary blobs that are
> clearly executable, running somewhere in the GPU. No-one seems
> to know, if those are copyrightable, or if they can be redistributed.
> In their current form, they have bee
http://bugs.freedesktop.org/show_bug.cgi?id=25544
--- Comment #2 from Alan Swanson 2009-12-10 12:43:09 PST
---
Yes, that patch resolves the error on R200 with no problems on rv250.
It looks like the texture unit differences and hardware bugs cause other issues
on R200 not present on rv250;
http://bugs.freedesktop.org/show_bug.cgi?id=25567
Summary: commit "drm/radeon/kms/r600/r700: fallback gracefully on
ucode failure" introduces screen corruption
Product: Mesa
Version: git
Platform: Other
OS/Version: All
Christian, I'd like to rebase your patches, correct some minor issue
with timer and try to post it.
I'm looking into your patch
0001-drm-radeon-kms-fix-HDMI-auto-detection.patch
Could you explain somehow please, why do you need to store EDID
per-encoder? What is wrong with (struct edid
*)connecto
On Thu, 10 Dec 2009 15:35:08 -0500
Will Dyson wrote:
> This seems similar to the unfortunate situation with the b43
> wireless card firmware. Broadcom refuses to provide the firmware
> under a redistributable license (or even as files separate from
> their proprietary drivers). This did not stop
2009/12/11 Rafał Miłecki :
> Christian, I'd like to rebase your patches, correct some minor issue
> with timer and try to post it.
>
> I'm looking into your patch
> 0001-drm-radeon-kms-fix-HDMI-auto-detection.patch
>
> Could you explain somehow please, why do you need to store EDID
> per-encoder? W
W dniu 10 grudnia 2009 22:18 użytkownik Dave Airlie napisał:
> 2009/12/11 Rafał Miłecki :
>> Christian, I'd like to rebase your patches, correct some minor issue
>> with timer and try to post it.
>>
>> I'm looking into your patch
>> 0001-drm-radeon-kms-fix-HDMI-auto-detection.patch
>>
>> Could you
On Thu, 10 Dec 2009 15:33:13 -0500
"C. Bergström" wrote:
> Pekka Paalanen
>
> > The big question is what we call ctxprogs: binary blobs that are
> > clearly executable, running somewhere in the GPU. No-one seems
> > to know, if those are copyrightable, or if they can be
> > redistributed. In the
> The big question is what we call ctxprogs: binary blobs that are
> clearly executable, running somewhere in the GPU. No-one seems
> to know, if those are copyrightable, or if they can be redistributed.
> In their current form, they have been recorded from the nvidia
> proprietary driver using mmi
2009/12/10 Rafał Miłecki :
> Christian, I'd like to rebase your patches, correct some minor issue
> with timer and try to post it.
>
> I'm looking into your patch
> 0001-drm-radeon-kms-fix-HDMI-auto-detection.patch
>
> Could you explain somehow please, why do you need to store EDID
> per-encoder? W
W dniu 10 grudnia 2009 22:46 użytkownik Alex Deucher
napisał:
> 2009/12/10 Rafał Miłecki :
>> Christian, I'd like to rebase your patches, correct some minor issue
>> with timer and try to post it.
>>
>> I'm looking into your patch
>> 0001-drm-radeon-kms-fix-HDMI-auto-detection.patch
>>
>> Could yo
http://bugs.freedesktop.org/show_bug.cgi?id=25567
--- Comment #1 from Alex Deucher 2009-12-10 13:50:55 PST ---
please include your dmesg and xorg log in the working and non-working cases.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving t
2009/12/10 Rafał Miłecki :
> W dniu 10 grudnia 2009 22:46 użytkownik Alex Deucher
> napisał:
>> 2009/12/10 Rafał Miłecki :
>>> Christian, I'd like to rebase your patches, correct some minor issue
>>> with timer and try to post it.
>>>
>>> I'm looking into your patch
>>> 0001-drm-radeon-kms-fix-HDM
http://bugs.freedesktop.org/show_bug.cgi?id=25567
--- Comment #2 from Florian Scandella 2009-12-10 14:02:05
PST ---
Created an attachment (id=31949)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31949)
dmesg working
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?ta
On Thu, Dec 10, 2009 at 4:59 PM, Christian König
wrote:
> Alex already fixed this if i remember correctly.
>
> And for the RV7xx HDMI case, we managed to get it working for resolution
> with lower pixel clocks (1024x768 and 640x480). but still now sound at
> 1280x768, 1280x1024 or even 1920x1080.
http://bugs.freedesktop.org/show_bug.cgi?id=25567
--- Comment #3 from Florian Scandella 2009-12-10 14:03:26
PST ---
Created an attachment (id=31950)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31950)
xorg.0.log working
for non working case i have to recompile the kernel first .. bu
2009/12/11 Alan Cox :
>> The big question is what we call ctxprogs: binary blobs that are
>> clearly executable, running somewhere in the GPU. No-one seems
>> to know, if those are copyrightable, or if they can be redistributed.
>> In their current form, they have been recorded from the nvidia
>> p
Alex already fixed this if i remember correctly.
And for the RV7xx HDMI case, we managed to get it working for resolution
with lower pixel clocks (1024x768 and 640x480). but still now sound at
1280x768, 1280x1024 or even 1920x1080. I really think the error is
somewhere in the timing setup, but can
http://bugs.freedesktop.org/show_bug.cgi?id=25567
--- Comment #5 from Florian Scandella 2009-12-10 14:21:47
PST ---
Created an attachment (id=31952)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31952)
xorg.0.log with corruption
--
Configure bugmail: http://bugs.freedesktop.org/use
http://bugs.freedesktop.org/show_bug.cgi?id=25567
--- Comment #4 from Florian Scandella 2009-12-10 14:21:18
PST ---
Created an attachment (id=31951)
--> (http://bugs.freedesktop.org/attachment.cgi?id=31951)
dmesg with corruption
--
Configure bugmail: http://bugs.freedesktop.org/userpref
* Alan Cox wrote:
> > Last time they were asked that, they wanted to be free of changing their
> > kernel/userspace interface before upstreaming.
>
> So put it in staging with a note to that effect. That'll also get it
> more exposure and review.
Well, arguably that particular idea should hav
2009/12/10 Alan Cox :
>> The big question is what we call ctxprogs: binary blobs that are
>> clearly executable, running somewhere in the GPU. No-one seems
>> to know, if those are copyrightable, or if they can be redistributed.
>> In their current form, they have been recorded from the nvidia
>> p
http://bugs.freedesktop.org/show_bug.cgi?id=25544
--- Comment #3 from Roland Scheidegger
2009-12-10 14:49:42 PST ---
(In reply to comment #2)
> Yes, that patch resolves the error on R200 with no problems on rv250.
>
> It looks like the texture unit differences and hardware bugs cause other
On Thu, 10 Dec 2009, Stephane Marchesin wrote:
>
> I'm not sure why people are arguing so much over this, given that no
> nouveau devs were at the kernel summit, and we only heard rumours
> afterwards that there were complaints about us not being ready for
> merging.
The thing is, my complaint
On Fri, Dec 11, 2009 at 9:37 AM, Linus Torvalds
wrote:
>
>
> On Thu, 10 Dec 2009, Stephane Marchesin wrote:
>>
>> I'm not sure why people are arguing so much over this, given that no
>> nouveau devs were at the kernel summit, and we only heard rumours
>> afterwards that there were complaints about
> But not only is Fedora not following the rules,
You changed the rules. You require a Signed-off-by:. Fedora can no more
add a signed off by than you can. It's not their code nor Red Hat's code
any more than they "own" the kernel because they pay someone to work on
it.
> See above. It's not you
On Fri, Dec 11, 2009 at 7:59 AM, Christian König
wrote:
> Alex already fixed this if i remember correctly.
>
> And for the RV7xx HDMI case, we managed to get it working for resolution
> with lower pixel clocks (1024x768 and 640x480). but still now sound at
> 1280x768, 1280x1024 or even 1920x1080.
On Thu, 10 Dec 2009, Alan Cox wrote:
>
> > But not only is Fedora not following the rules,
>
> You changed the rules. You require a Signed-off-by:. Fedora can no more
> add a signed off by than you can. It's not their code nor Red Hat's code
> any more than they "own" the kernel because they pa
>
> I realize that you have some emotional attachments to Red Hat, but ask
> yourself (and answer honestly): what would you think if some random other
> distro was packaging tens of thousands of lines of kernel code and not
> apparently working at trying to get them upstream?
Lots of distros do th
On Thu, 10 Dec 2009, "C. Bergström" wrote:
>
> Thanks for the rather lengthly explanation, but in case you missed what people
> are trying to say here..
>
> With all due respect Linus..
>
> "patches welcome"
The problem is that I have never even heard a Red Hat or Fedora person
actually ac
On Fri, 11 Dec 2009, Dave Airlie wrote:
>
> I'm going to see what Ben can do with a firmware loader and the ctxprogs,
> we can send a patch that contains all the other bits of the driver, however
> since the ctxprogs aren't currently something we can add Signed-off-by to,
> someone else will hav
2009/12/11 Linus Torvalds :
>
>
> On Thu, 10 Dec 2009, "C. Bergström" wrote:
>>
>> Thanks for the rather lengthly explanation, but in case you missed what
>> people
>> are trying to say here..
>>
>> With all due respect Linus..
>>
>> "patches welcome"
>
> The problem is that I have never even hear
On Fri, 11 Dec 2009, Dave Airlie wrote:
> I've rebaseed Christian's last patch and fixed up a bunch of
> patchcheck violations in it,
>
> its sitting on drm-radeon-testing branch of my git repo, please test
> it if you can as I've
> no HDMI audio.
>
> Hopefully when Alex clears IP review he can pro
Linus Torvalds wrote:
> On Thu, 10 Dec 2009, Alan Cox wrote:
>
>>> But not only is Fedora not following the rules,
>>>
>> You changed the rules. You require a Signed-off-by:. Fedora can no more
>> add a signed off by than you can. It's not their code nor Red Hat's code
>> any more than t
2009/12/11 Brian Paterni :
> On Fri, 11 Dec 2009, Dave Airlie wrote:
>>
>> I've rebaseed Christian's last patch and fixed up a bunch of
>> patchcheck violations in it,
>>
>> its sitting on drm-radeon-testing branch of my git repo, please test
>> it if you can as I've
>> no HDMI audio.
>>
>> Hopeful
Hi again here is a slightly updated version of the vmwgfx driver. Its the
same driver plus what ever changes has been made inside the vmwgfx repo.
So not really anything interesting.
The driver compiles and run on drm-core-next.
Comments please?
Hopefully this time the mails wont get stuck somew
On Fri, Dec 11, 2009 at 5:51 AM, Thomas Hellstrom wrote:
> Jerome Glisse wrote:
>>
>> Hi,
>>
>> So here is a patch which convert bo_init to use struct ttm_placement
>> rather than flag. It allow the driver to give placement preference
>> on where to create a bo. Also allow to create a bo at specif
On Thu, Dec 10, 2009 at 04:32:56PM -0800, Linus Torvalds wrote:
> > "patches welcome"
>
> The problem is that I have never even heard a Red Hat or Fedora person
> actually acknoledge that yes, they should be trying to upstream it.
>
> Have Red Hat and Fedora just decided that "upstream first" si
When the agp driver is not compiled in but is build as module, the kernel oopes
on modprobing radeon with modeset=1.
Dec 7 22:08:53 datengrab kernel: BUG: unable to handle kernel NULL pointer
dereference at 0074
Dec 7 22:08:53 datengrab kernel: IP: []
radeon_agp_init+0x18/0x23c [
80 matches
Mail list logo
