[OOPS] Radeon KMS with 2.6.32 and agp not compiled in
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 [radeon] Dec 7 22:08:53 datengrab kernel: PGD 0 Dec 7 22:08:53 datengrab kernel: Oops: [#1] SMP Dec 7 22:08:53 datengrab kernel: last sysfs file: /sys/module/agpgart/initstate Dec 7 22:08:53 datengrab kernel: CPU 0 Dec 7 22:08:53 datengrab kernel: Modules linked in: radeon(+) ttm drm_kms_helper drm i2c_algo_bit snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss aes_x86_64 aes_generic xts gf128mul dm_crypt snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem snd_hwdep ohci_hcd i2c_amd8111 uhci_hcd sg snd amd64_agp sata_sil k8temp agpgart i2c_amd756 sr_mod hwmon Dec 7 22:08:53 datengrab kernel: Pid: 2531, comm: work_for_cpu Not tainted 2.6.32 #2 To Be Filled By O.E.M. Dec 7 22:08:53 datengrab kernel: RIP: 0010:[] [] radeon_agp_init+0x18/0x23c [radeon] Dec 7 22:08:53 datengrab kernel: RSP: 0018:8801172c3d80 EFLAGS: 00010282 Dec 7 22:08:53 datengrab kernel: RAX: RBX: 88011841 RCX: 88011fb97800 Dec 7 22:08:53 datengrab kernel: RDX: c000 RSI: RDI: 88011e43d800 Dec 7 22:08:53 datengrab kernel: RBP: R08: a0238201 R09: 8801172c3d90 Dec 7 22:08:53 datengrab kernel: R10: 81589940 R11: 0400 R12: 88011fb97800 Dec 7 22:08:53 datengrab kernel: R13: 0020 R14: a0243240 R15: 88011e43dbc0 Dec 7 22:08:53 datengrab kernel: FS: 7f0e85a7f700() GS:88002820() knlGS: Dec 7 22:08:53 datengrab kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Dec 7 22:08:53 datengrab kernel: CR2: 0074 CR3: 01001000 CR4: 06f0 Dec 7 22:08:53 datengrab kernel: DR0: DR1: DR2: Dec 7 22:08:53 datengrab kernel: DR3: DR6: 0ff0 DR7: 0400 Dec 7 22:08:53 datengrab kernel: Process work_for_cpu (pid: 2531, threadinfo 8801172c2000, task 8801188d2280) Dec 7 22:08:53 datengrab kernel: Stack: Dec 7 22:08:53 datengrab kernel: 88011e43dbc0 813436f0 88010008 8801172c3df0 Dec 7 22:08:53 datengrab kernel: <0> 8801172c3db0 0246 88011841 880118410144 Dec 7 22:08:53 datengrab kernel: <0> 0282 88011841 88011fb97800 Dec 7 22:08:53 datengrab kernel: Call Trace: Dec 7 22:08:53 datengrab kernel: [] ? printk+0x40/0x48 Dec 7 22:08:53 datengrab kernel: [] ? r600_mc_init+0xf0/0x251 [radeon] Dec 7 22:08:53 datengrab kernel: [] ? r600_init+0x154/0x2b7 [radeon] Dec 7 22:08:53 datengrab kernel: [] ? radeon_device_init+0x1fe/0x276 [radeon] Dec 7 22:08:53 datengrab kernel: [] ? radeon_driver_load_kms+0xb2/0xec [radeon] Dec 7 22:08:53 datengrab kernel: [] ? drm_get_dev+0x322/0x42e [drm] Dec 7 22:08:53 datengrab kernel: [] ? do_work_for_cpu+0x0/0x1b Dec 7 22:08:53 datengrab kernel: [] ? local_pci_probe+0x12/0x16 Dec 7 22:08:53 datengrab kernel: [] ? do_work_for_cpu+0xb/0x1b Dec 7 22:08:53 datengrab kernel: [] ? kthread+0x75/0x7d Dec 7 22:08:53 datengrab kernel: [] ? child_rip+0xa/0x20 Dec 7 22:08:53 datengrab kernel: [] ? kthread+0x0/0x7d Dec 7 22:08:53 datengrab kernel: [] ? child_rip+0x0/0x20 Dec 7 22:08:53 datengrab kernel: Code: 48 85 c0 74 0c 83 78 74 00 74 06 5a e9 c3 5e fa ff 58 c3 41 55 41 54 55 53 48 89 fb 48 83 ec 48 48 8b 7f 08 48 8b 87 48 03 00 00 <83> 78 74 00 75 1d e8 38 5e fa ff 85 c0 89 c5 74 12 89 c2 48 c7 Dec 7 22:08:53 datengrab kernel: RIP [] radeon_agp_init+0x18/0x23c [radeon] Dec 7 22:08:53 datengrab kernel: RSP Dec 7 22:08:53 datengrab kernel: CR2: 0074 Dec 7 22:08:53 datengrab kernel: ---[ end trace b9e94e547b237285 ]--- -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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" simply doesn't > matter any more? Because quite frankly, that was kind of the feeling I > came away with from the Kernel summit. > Well, given that none of the Fedora kernel people were able to attend this year for a variety of reasons, this is an interesting revelation to me, I wasn't aware I thought this. I, for one, would very much like nouveau to be upstream. It would certainly make my life easier not having to worry about subtlely breaking graphics adapters I can't test whenever we rebase to new git changes in the DRM. Thankfully Ben and Dave have been ninja at dealing with it, otherwise I probably would have punted it by now. > It's like they _want_ to keep it internal. > regards, Kyle -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] TTM change buffer_object_init to use ttm_placement rather than flag
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 specific range >> which is i believe somethings nouveau would like to see :) >> >> Aside from the change i renamed ttm_buffer_object_init|validate to >> ttm_bo_init|validate this is shorter but also more consistent with >> others functions naming. For consistency i would like to rename >> struct ttm_buffer_object to struct ttm_bo but this lead to massive >> regular expression abuse for everyone using ttm so before proposing >> a patch let me know if you like or not this. I haven't strong >> feeling on that except that this would allow to stay in the 80 line >> lenght in some place. >> >> Cheers, >> Jerome >> >> > > Jerome, this looks good and consistent with previous changes. > > In order to get the vmwgfx driver ready for upstream in the not too distant > future we need a (temporarily) stable API. Is this patch targeted for > 2.6.33? I'm happy to pull this into drm-core-next and make it the last API change for 2.6.33. I'd like to base vmware and nouveau merges on that TTM API and get them in ASAP. They can go into staging after merge window if necessary. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/2] Slightly updated version of the vmwgfx driver
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 somewhere. Cheers Jakob. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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. >> >> Hopefully when Alex clears IP review he can provides fixes on top and >> we'll all be happy. >> >> Dave. > > I believe there is a small typo in r600_hdmi.c:105 > > -for (i = 0; (r600_hdmi_ACR[i].Clock != clock && r600_hdmi_ACR[i].Clock != > 0; i++); > +for (i = 0; r600_hdmi_ACR[i].Clock != clock && r600_hdmi_ACR[i].Clock != 0; > i++); > Oops had fixed it locally but didn't run the correct git commit --amend. pushed now should be mirrored in 5 mins or so. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 they "own" the kernel because they pay someone to work on >> it. >> > > You're avoiding the point: they are shipping it, they are paying for (at > least some) development, and they seem to not even want to face the issue. > > Sign-offs aren't some new feature that took Red Hat people by surprise. > The "get it merged upstream first" didn't change in any way from it: it > just codified existing practice - of _course_ everybody expects copyrights > to be honored and clear. > > >> It's really simple: if you want to merge it *you* pull it and sign it off. >> If you aren't prepared to do that then ask why Fedora should, its not >> their code either. >> > > I'm not shipping it. They are. That's the difference. > > 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? > > Dave claims it's only been going on for a few months, but quite frankly, > we all know better. The nouveau kernel modules have been shipped for a lot > longer than just F12. > > And it's possible that other distros are doing the same thing. I happen to > know that Fedora does it (and has been doing it for at least a year), > because I happen to have an Intel development machine that runs Fedora and > was shipped by Intel with an nVidia card (and has a power supply that > craps out if you don't use several hundred watts of power, so I can't > change it to something more power-efficient - seriously). > 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" -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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 provides fixes on top and > we'll all be happy. > > Dave. I believe there is a small typo in r600_hdmi.c:105 -for (i = 0; (r600_hdmi_ACR[i].Clock != clock && r600_hdmi_ACR[i].Clock != 0; i++); +for (i = 0; r600_hdmi_ACR[i].Clock != clock && r600_hdmi_ACR[i].Clock != 0; i++); -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 heard a Red Hat or Fedora person > actually acknoledge that yes, they should be trying to upstream it. We are trying to upstream nouveau. The core DRM changes to support nouveau were but ugly, and shared with radeon and vmware, we need to wait for VMware to re-write them. VMware have rewritten them and they are upstream since radeon KMS got merged into staging. The ctxprogs are legally dubious, we need to wait for Red Hat lawyers to give us some direction, we can involve other lawyers but more lawyers doesn't always help these things go faster. nvidia guys are laughing at us. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 have to endeavour to provide them some other way. Hey, thanks. This was actually the first time I got the feeling that you acknowledged that we should strive for it to be merged at all. I literally feel better for just that. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 acknoledge that yes, they should be trying to upstream it. Have Red Hat and Fedora just decided that "upstream first" simply doesn't matter any more? Because quite frankly, that was kind of the feeling I came away with from the Kernel summit. It's like they _want_ to keep it internal. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> > 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 this all the time, you just don't have any hardware or care about it. If you didn't have an nvidia box you wouldn't care about this either. If I send you an LIRC remote will you bitch about LIRC not being upstream and Fedora/Ubuntu/everyone else shipping it? > > Dave claims it's only been going on for a few months, but quite frankly, > we all know better. The nouveau kernel modules have been shipped for a lot > longer than just F12. No I know exactly how long we've had the code in Fedora, it predates both mine and Ben's employment at Red Hat. But it doesn't change the fact the code has only in the last 2-3 months gotten to a stage where the core DRM code was able to support it, mainly due to radeon KMS work being pushed. Previous nouveau drivers shipped were either UMS with an API that nobody wanted upstream, or KMS with a reliance on a core DRM feature that no-one wanted upstream. We've been resolving those issues first, while hoping the lawyers could deal with ctxprogs, guess we moved faster than them. 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 have to endeavour to provide them some other way. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 pay someone to work on > it. You're avoiding the point: they are shipping it, they are paying for (at least some) development, and they seem to not even want to face the issue. Sign-offs aren't some new feature that took Red Hat people by surprise. The "get it merged upstream first" didn't change in any way from it: it just codified existing practice - of _course_ everybody expects copyrights to be honored and clear. > It's really simple: if you want to merge it *you* pull it and sign it off. > If you aren't prepared to do that then ask why Fedora should, its not > their code either. I'm not shipping it. They are. That's the difference. 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? Dave claims it's only been going on for a few months, but quite frankly, we all know better. The nouveau kernel modules have been shipped for a lot longer than just F12. And it's possible that other distros are doing the same thing. I happen to know that Fedora does it (and has been doing it for at least a year), because I happen to have an Intel development machine that runs Fedora and was shipped by Intel with an nVidia card (and has a power supply that craps out if you don't use several hundred watts of power, so I can't change it to something more power-efficient - seriously). Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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. I really think the error is > somewhere in the timing setup, but can't figure out where. > 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 provides fixes on top and we'll all be happy. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> 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. It's Fedora. If Fedora hadn't merged Nouveau and > shipped it, I wouldn't care. And zillions of Nvidia users would have been worse off. It's really simple: if you want to merge it *you* pull it and sign it off. If you aren't prepared to do that then ask why Fedora should, its not their code either. Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 us not being ready for >> merging. > > The thing is, my complaint is not about whatever external driver project. > > We have those all the time. I'm not complaining about Nouveau people. > > I'm pissed off at distribution people. For years now, distributions have > talked about "upstream first", because of the disaster and fragmentation > that was Linux-2.4. And most of them do it, and have been fairly good > about it. > > But not only is Fedora not following the rules, I know that Fedora people > are actively making excuses about not following the rules. I know Red Hat > actually employs (full-time or part-time I have no idea) some Nouveau > dveloper, and by that point Red Hat should also man up and admit that they > need to make "merge upstream" be a priority for them. > > See? I'm not complaining about _you_. I'm complaining about Fedora and Red > Hat. > >> If you have issues to raise about nouveau, please raise them on the >> nouveau, mesa or dri lists, at least some time before starting to >> complain. I must say I didn't think such a big issue was going on >> here, that's the problem with rumours. > > See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and > shipped it, I wouldn't care. > > Or rather, I probably still -would- care, but I would care because nVidia > hardware is common, and I like open source drivers. But I wouldn't be > disappointed and pissed off. > > And this has been going on for a _loong_ time now. Fedora has been > shipping Nouveau for about a year now, I think. Its been shipping it for 2-3 years now, nouveau was a userspace X.org driver with a normal drm, we never wanted to upstream that but we need to get some exposure on it before the KMS effort took place. In my opinion barring the legal issue, nouveau has only been in an upstreamable state for about 2-3 months now, since it relied on a lot of core infrastructure we upstreamed with radeon KMS. So the delay isn't as major as you seem to think. The core TTM infrastructure we based radeon and nouveau on in F10, and F11 wasn't in any state suitable for upstream, however we felt it would help to expose the modesetting pieces to users before then to get them tested independent of the core DRM status. So Red Hat have been putting a lot of time and effort into upstreaming this driver, however until the ctxprog issues is resolved to our satisfaction, no Red Hat employee can add a Signed-off-by to this code. Why this doesn't affect Fedora so far is because its an open question with our lawyers, if they decide that we need to pull this from Fedora we will, until they do we are living with the status quo. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 is not about whatever external driver project. We have those all the time. I'm not complaining about Nouveau people. I'm pissed off at distribution people. For years now, distributions have talked about "upstream first", because of the disaster and fragmentation that was Linux-2.4. And most of them do it, and have been fairly good about it. But not only is Fedora not following the rules, I know that Fedora people are actively making excuses about not following the rules. I know Red Hat actually employs (full-time or part-time I have no idea) some Nouveau dveloper, and by that point Red Hat should also man up and admit that they need to make "merge upstream" be a priority for them. See? I'm not complaining about _you_. I'm complaining about Fedora and Red Hat. > If you have issues to raise about nouveau, please raise them on the > nouveau, mesa or dri lists, at least some time before starting to > complain. I must say I didn't think such a big issue was going on > here, that's the problem with rumours. See above. It's not you. It's Fedora. If Fedora hadn't merged Nouveau and shipped it, I wouldn't care. Or rather, I probably still -would- care, but I would care because nVidia hardware is common, and I like open source drivers. But I wouldn't be disappointed and pissed off. And this has been going on for a _loong_ time now. Fedora has been shipping Nouveau for about a year now, I think. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25544] KMS/R200: CS section size missmatch start at (r200_state_init.c,tex_emit_mm,703) 5 vs 9
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 > issues > on R200 not present on rv250; dark and strobed textures with Compiz alt-tab > and > cube effects whilst running most games crash on a "drmRadeonCmdBuffer: -22" > error with the following dmesg. > > [drm:r100_cs_track_texture_check] *ERROR* No texture bound to unit 1 > [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! > > I'll open another bug after a bit more testing as I've just started using KMS. Looks like the command verifier isn't getting along with fake enable of texture unit 1. So in some cases when unit 0 is active and 1 is not, we need to enable unit 1 too due to hw bug, but set to LOOKUP_DISABLE. Since that'll not actually sample from the "enabled" unit, that's just fine and it's not necessary a texture is bound on that unit. But cs_track_texture_check can't deal with that since it only sees unit 1 is enabled but no texture is actually bound and hence complains... I don't know how to fix this though, could either make the track_texture_check more clever or maybe the userspace driver should just bind some valid texture (maybe just take the one from unit 0?) so it doesn't look special from the kernel side. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 >> proprietary driver using mmiotrace, and copied verbatim for each >> card type. > > Don't suppose they binary match anything in the Nvidia driver so you can > simply tell people where to extract it ? > There is a (actually multiple for different card generations) stub of the firmware visible in the binary, but it can't be used as-is, it has to be tailored to each card. Stephane -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
* 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 have come from the people maintaining that area of code. There's this one missing driver which covers (more or less) like 40%-50% of the PC market, that's a glaringly significant issue, isnt it? It doesnt get any more significant, does it? Ingo -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" introduces screen corruption
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/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" introduces screen corruption
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/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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't figure out where. @Alex: If you could give me a hint what i'm doing wrong i would be very happy. Regards, Christian. Am Donnerstag, den 10.12.2009, 22:10 +0100 schrieb 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? What is wrong with (struct edid > *)connector->edid_blob_ptr? > > Also could you btw. sum up state of your last-published: > 0002-drm-radeon-kms-HDMI-support-for-R600-KMS.patch > ? I know of course it does not support RV7x0 which is problematic for > now. But except that is there something we need to change in this > patch before commiting? > > I'd appreciate some help, explanations :) > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 >> proprietary driver using mmiotrace, and copied verbatim for each >> card type. > > Don't suppose they binary match anything in the Nvidia driver so you can > simply tell people where to extract it ? In theory that would require a level of RE on the blob we aren't willing to do. But from what I think we know, there isn't a 1:1 binary between blob and what goes out in mmiotrace. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" introduces screen corruption
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 .. but as far as i could see, there was no difference -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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. I really think the error is > somewhere in the timing setup, but can't figure out where. > > @Alex: > If you could give me a hint what i'm doing wrong i would be very happy. > Going through the IP review on this info now. Alex > Regards, > Christian. > > Am Donnerstag, den 10.12.2009, 22:10 +0100 schrieb 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? What is wrong with (struct edid >> *)connector->edid_blob_ptr? >> >> Also could you btw. sum up state of your last-published: >> 0002-drm-radeon-kms-HDMI-support-for-R600-KMS.patch >> ? I know of course it does not support RV7x0 which is problematic for >> now. But except that is there something we need to change in this >> patch before commiting? >> >> I'd appreciate some help, explanations :) >> > > > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" introduces screen corruption
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?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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-HDMI-auto-detection.patch >>> >>> Could you explain somehow please, why do you need to store EDID >>> per-encoder? What is wrong with (struct edid >>> *)connector->edid_blob_ptr? >>> >> >> I've already fixed this. This patch isn't needed anymore. > > Out of curiosity could you tell what was wrong with old solution? > Maybe sb will finally explain that to me :) edid_blob_ptr is not a pointer to an edid struct. Alex -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" introduces screen corruption
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 this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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 you explain somehow please, why do you need to store EDID >> per-encoder? What is wrong with (struct edid >> *)connector->edid_blob_ptr? >> > > I've already fixed this. This patch isn't needed anymore. Out of curiosity could you tell what was wrong with old solution? Maybe sb will finally explain that to me :) -- Rafał -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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? What is wrong with (struct edid > *)connector->edid_blob_ptr? > I've already fixed this. This patch isn't needed anymore. Alex > Also could you btw. sum up state of your last-published: > 0002-drm-radeon-kms-HDMI-support-for-R600-KMS.patch > ? I know of course it does not support RV7x0 which is problematic for > now. But except that is there something we need to change in this > patch before commiting? > > I'd appreciate some help, explanations :) > > -- > Rafał > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> 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 mmiotrace, and copied verbatim for each > card type. Don't suppose they binary match anything in the Nvidia driver so you can simply tell people where to extract it ? -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Nouveau ctxprogs (Re: [git pull] drm)
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 their current form, they have been recorded > > from the nvidia proprietary driver using mmiotrace, and copied > > verbatim for each card type. > > --- > (apologies about the copy paste of thread, but I'm joining the > list late) > > Please see my other response. From my perspective there is only > technical issues remaining and no license issues. I am just > evaluating and receiving information from one of the nouveau > devs. However, ctxprogs was obtained in the same way that the > rest of the information was via dumping from the mmio-traces. > (As stated above) When Nouveau is able to generate ctxprogs itself, I completely agree. But the current situation is a little different. We are not collecting just the basic blocks individually like has been done for everything else. We are copying a complete program or something that is a non-trivial composition. The proprietary driver might be generating it on the fly from basic blocks, or it might contain the complete programs. We only see the stream of data going into the card. Apparently there is also freedom to do things right more than one way(?), so it is not trivial in the sense that the hardware would force it to be exactly what we see. How sure you are that there won't be a problem and that it is not "actually copying a copyrighted work"? Did you already see things the way I put it here? Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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 explain somehow please, why do you need to store EDID >> per-encoder? What is wrong with (struct edid >> *)connector->edid_blob_ptr? > > I think we should do like we do for the use_digital flag if we can, > just store the is hdmi bit then and use it later. Yeah, but still... what's wrong with current solution? Maybe it eats some more CPU cycles instead of memory bits, but should work... > I was going to take a look at rebasing these but thanks for looking. When could you work on it? -- Rafał -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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? What is wrong with (struct edid > *)connector->edid_blob_ptr? I think we should do like we do for the use_digital flag if we can, just store the is hdmi bit then and use it later. I was going to take a look at rebasing these but thanks for looking. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 b43 from being > included in Linux. Distributions have dealt with it by providing > a script that downloads the proprietary driver and extracts the > firmware from it to files in /lib/firmware. > > Do you think that a similar solution for nouveau would be legally > problematic? Or is the issue technical, since you mention that the > ctxprogs were obtained by mmiotrace, instead of a more > straightforward extraction from the binary driver blobs? It is definitely a lot harder than a script that just downloads something. It would have to: - download the proprietary driver - install it and load it into the kernel - activate mmiotrace (if it even is compiled in) - reconfigure and start X and quit - analyse the mmiotrace log to extract the ctxprog and ctxvals - undo all the proprietary setup I cannot comment on the legal side, but the practise sounds too cumbersome. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm/radeon/kms: drm_detect_hdmi_monitor issue with EDID?
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 *)connector->edid_blob_ptr? Also could you btw. sum up state of your last-published: 0002-drm-radeon-kms-HDMI-support-for-R600-KMS.patch ? I know of course it does not support RV7x0 which is problematic for now. But except that is there something we need to change in this patch before commiting? I'd appreciate some help, explanations :) -- Rafał -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] New: commit "drm/radeon/kms/r600/r700: fallback gracefully on ucode failure" introduces screen corruption
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 Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: f...@chilicode.com observed on rv770, mesa+librm+ddx git, linux 2.6.32.y+drm-radeon-testing massive screen corruptions, mostly fonts are garbage. reverting the commit (779720a3209849be202ac36a811e934865c50971) fixes the problem (already reported on irc) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25544] KMS/R200: CS section size missmatch start at (r200_state_init.c,tex_emit_mm,703) 5 vs 9
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; dark and strobed textures with Compiz alt-tab and cube effects whilst running most games crash on a "drmRadeonCmdBuffer: -22" error with the following dmesg. [drm:r100_cs_track_texture_check] *ERROR* No texture bound to unit 1 [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! I'll open another bug after a bit more testing as I've just started using KMS. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 been recorded from the nvidia > proprietary driver using mmiotrace, and copied verbatim for each > card type. > > Would you be willing to pull that kind of stuff into Linux? > > I would not even dare sending them to the Linux firmware > repository, since they have some license requirements, too. 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 b43 from being included in Linux. Distributions have dealt with it by providing a script that downloads the proprietary driver and extracts the firmware from it to files in /lib/firmware. Do you think that a similar solution for nouveau would be legally problematic? Or is the issue technical, since you mention that the ctxprogs were obtained by mmiotrace, instead of a more straightforward extraction from the binary driver blobs? -- Will Dyson -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 merge" excuse too - which I also > know is bullshit, because I can look at the git tree Fedora > apparently uses, and it merges without any conflicts what-so-ever. No-one has said that about Nouveau, have they? > The most common excuse is the "oh, but it might change" crap. But > that's not even a very good excuse to start with, and it's what > staging is for anyway. Yes, and to my understanding Nouveau is past that excuse. People just like to quote what they heard last. 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 mmiotrace, and copied verbatim for each card type. Would you be willing to pull that kind of stuff into Linux? I would not even dare sending them to the Linux firmware repository, since they have some license requirements, too. --- (apologies about the copy paste of thread, but I'm joining the list late) Please see my other response. From my perspective there is only technical issues remaining and no license issues. I am just evaluating and receiving information from one of the nouveau devs. However, ctxprogs was obtained in the same way that the rest of the information was via dumping from the mmio-traces. (As stated above) -- So beyond all this I have been in discussion with someone at nv about their view. I have a call setup for next Monday and anyone interested to participate or listen in please ping me off list. ./C -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] Add verbose debug information when eviction fails
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, although we should only enable it on debug, and remove the existing error message as well. The reason for this is as follows: When we get an out of memory error, it may be due to conditions that we should recover from without error: 1) Concurrent memory manager use. (not applicable on Radeon since you use a single mutex for validation). The remedy for concurrent drivers is to take the validation lock in write mode to block concurrent users and retry. 2) Fragmentation. The remedy for this is to evict all evictable buffers and retry. When these two steps are tried and have failed, only then we should give an error message, and only the driver can do that. /Thomas -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/2] RFC: Upstreaming the vmwgfx driver
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 rejected due to thier uglyness. So I will clean them up before > the final patch series. > > There are some checkpatch warnings in the second patch but only > width 80. If I have the time I will also change the fbdev code to > use the drm_fb_helper code. > > Comments please? > > Cheers Jakob. > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > Hmm. I see it hasn't been adapted to Jerome's latest TTM changes. Dave, what branch should we be basing this off? Thanks, Thomas -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> 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 quicker. I don't have any nvidia hardware. Someone send me an ion netbook and I'll take care of converting nouveau to firmware loader :) - R. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 the copyright of some >> (essential) microcode. Either the question needs to be answered, or it >> has to be reverse engineered to the point that it's possible to >> generate it. > > I think people are just making up excuses, as evidenced by the fact that > you're quoting a different excuse than I've heard before. > > The fact is, if there are license questions, then Fedora had better not be > distributing the code either. And they clearly are. > > And don't tell me about "full control". There's absolutely full control > over it being included or not. > > When I brought this up at the kernel summit, there were various other > random excuses. I think one of them was that it wasn't part of an official > Fedora release (which is sure as hell not true at least as of Fedora 12). > > I've heard the "but it's hard to merge" excuse too - which I also know is > bullshit, because I can look at the git tree Fedora apparently uses, and > it merges without any conflicts what-so-ever. > > The most common excuse is the "oh, but it might change" crap. But that's > not even a very good excuse to start with, and it's what staging is for > anyway. > > Somebody even made the crazy comment that "but Fedora isn't a real > distribution, so it doesn't need to follow the rules everybody agreed to > several _years_ ago wrt merging stuff to mainline". > > 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 is wrong. > 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. If you have issues to raise about nouveau, please raise them on the nouveau, mesa or dri lists, at least some time before starting to complain. I must say I didn't think such a big issue was going on here, that's the problem with rumours. Stephane (nouveau founder). -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 this licensing bs.. Someone from SFLC was kind enough to provide.. (copy/paste with part not needed omitted) Generally, there are three ways to infringe copyright: actually copying (or modifying or distributing) a copyrighted work (a typical copyright infringement), circumventing a technological measure that controls access to a copyrighted work (a DMCA violation), or violating the license that gave you the right to copy the work to begin with (a EULA violation). If the Nouveau FAQ is correct, and they are not copying or modifying NVidia's blob, then this cannot be a copyright infringement in the classic sense. I also don't think that monitoring GPU register activity or the graphics card's memory is a DMCA violation. Neither of these data are copyrighted material. The blob is, but Nouveau isn't trying to access the blob, and I see no evidence that NVidia has used any technological measures to protect it anyway. ... An important disclaimer in case you intend to share this email with anyone at the Nouveau project: please keep in mind that this is privileged advice for you, and not for the Nouveau project generally. If you chose to share any of this information with the Nouveau project or any third party, you would wave attorney-client privilege regarding this email and the third party should not rely on this advice, but should seek their own counsel. - ./C -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] TTM change buffer_object_init to use ttm_placement rather than flag
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 :) > > Aside from the change i renamed ttm_buffer_object_init|validate to > ttm_bo_init|validate this is shorter but also more consistent with > others functions naming. For consistency i would like to rename > struct ttm_buffer_object to struct ttm_bo but this lead to massive > regular expression abuse for everyone using ttm so before proposing > a patch let me know if you like or not this. I haven't strong > feeling on that except that this would allow to stay in the 80 line > lenght in some place. > > Cheers, > Jerome > > Jerome, this looks good and consistent with previous changes. In order to get the vmwgfx driver ready for upstream in the not too distant future we need a (temporarily) stable API. Is this patch targeted for 2.6.33? /Thomas -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 questions over the > > copyright of some (essential) microcode. Either the question > > needs to be answered, or it has to be reverse engineered to the > > point that it's possible to generate it. > > I think people are just making up excuses, as evidenced by the > fact that you're quoting a different excuse than I've heard > before. That is because priorities change. The ABI has not seen changes for some time now, so it's probably not an issue anymore. And it is not an issue for staging. The other issue has become more important. That said, there are features that likely require revising the ABI at some point, and we know about those already. > 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 merge" excuse too - which I also > know is bullshit, because I can look at the git tree Fedora > apparently uses, and it merges without any conflicts what-so-ever. No-one has said that about Nouveau, have they? > The most common excuse is the "oh, but it might change" crap. But > that's not even a very good excuse to start with, and it's what > staging is for anyway. Yes, and to my understanding Nouveau is past that excuse. People just like to quote what they heard last. 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 mmiotrace, and copied verbatim for each card type. Would you be willing to pull that kind of stuff into Linux? I would not even dare sending them to the Linux firmware repository, since they have some license requirements, too. -- Pekka Paalanen http://www.iki.fi/pq/ -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 the copyright of some >> (essential) microcode. Either the question needs to be answered, or it >> has to be reverse engineered to the point that it's possible to >> generate it. > > I think people are just making up excuses, as evidenced by the fact that > you're quoting a different excuse than I've heard before. > > The fact is, if there are license questions, then Fedora had better not be > distributing the code either. And they clearly are. Alan mentioned this at KS, Fedora shipping something and RH taking responsibility or something going upstream to you and then into multiple other distros that aren't RH controlled are completely different questions from the lawyers point of view. At the moment we cannot provide a Signed-off version of nouveau, I don't think you are willing to accept stuff without Signed-off-by's unless something has changed recently. > > And don't tell me about "full control". There's absolutely full control > over it being included or not. While its not Red Hat's decision, we pay one of the nouveau developers to work on it, but the project consists of a lot more than him, and RH generally doesn't order upstreams to do stuff they aren't comfortable with. 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 quicker. Dave. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 is wrong. Heh. I was only half-kidding. My point was that Fedora (for the purposes of graphics at least) is more like an individual developer's (or small group's) work tree that just happens to be available publicly. If you think of it that way, it kind of makes sense that some changes it includes aren't pushed upstream right away. But I fully admit it's a bogus excuse and a fairly cheap shot at Fedora. :) -- Jesse Barnes, Intel Open Source Technology Center -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> 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 > bullshit, because I can look at the git tree Fedora apparently uses, and > it merges without any conflicts what-so-ever. So merge it - it's your call as the maintainer of the master tree - or put it in staging and dike out the microcode - which is firmware tree stuff *anyway* Alan -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 lawyers involved, it appears rather questionable. robert. -- Robert Noland 2Hip Networks -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 the question needs to be answered, or it >> has to be reverse engineered to the point that it's possible to >> generate it. On Thu, Dec 10, 2009 at 8:42 PM, Linus Torvalds wrote: > I think people are just making up excuses, as evidenced by the fact that > you're quoting a different excuse than I've heard before. AFAICT, the "problem" here is that the guys running the nouveau project are simply not interested in merging the damn thing. I guess at some point one of us just needs to grab the code and send it to Greg for inclusion in -staging? Pekka -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 question needs to be answered, or it > has to be reverse engineered to the point that it's possible to > generate it. I think people are just making up excuses, as evidenced by the fact that you're quoting a different excuse than I've heard before. The fact is, if there are license questions, then Fedora had better not be distributing the code either. And they clearly are. And don't tell me about "full control". There's absolutely full control over it being included or not. When I brought this up at the kernel summit, there were various other random excuses. I think one of them was that it wasn't part of an official Fedora release (which is sure as hell not true at least as of Fedora 12). I've heard the "but it's hard to merge" excuse too - which I also know is bullshit, because I can look at the git tree Fedora apparently uses, and it merges without any conflicts what-so-ever. The most common excuse is the "oh, but it might change" crap. But that's not even a very good excuse to start with, and it's what staging is for anyway. Somebody even made the crazy comment that "but Fedora isn't a real distribution, so it doesn't need to follow the rules everybody agreed to several _years_ ago wrt merging stuff to mainline". 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 is wrong. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 ship it to > millions of people. And if it's ready, they should work on merging it. 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 question needs to be answered, or it has to be reverse engineered to the point that it's possible to generate it. > > No excuses. > > Linus > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
> 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 -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Fix memory type manager debug information printing
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, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fc13f63..adaee6e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -71,9 +71,10 @@ static inline int ttm_mem_type_from_flags(uint32_t flags,
uint32_t *mem_type)
return -EINVAL;
}
-static void ttm_mem_type_manager_debug(struct ttm_bo_global *glob,
- struct ttm_mem_type_manager *man)
+static void ttm_mem_type_debug(struct ttm_bo_device *bdev, int mem_type)
{
+ struct ttm_mem_type_manager *man = &bdev->man[mem_type];
+
printk(KERN_ERR TTM_PFX "has_type: %d\n", man->has_type);
printk(KERN_ERR TTM_PFX "use_type: %d\n", man->use_type);
printk(KERN_ERR TTM_PFX "flags: 0x%08X\n", man->flags);
@@ -85,17 +86,16 @@ static void ttm_mem_type_manager_debug(struct ttm_bo_global
*glob,
man->available_caching);
printk(KERN_ERR TTM_PFX "default_caching: 0x%08X\n",
man->default_caching);
- spin_lock(&glob->lru_lock);
- drm_mm_debug_table(&man->manager, TTM_PFX);
- spin_unlock(&glob->lru_lock);
+ if (mem_type != TTM_PL_SYSTEM) {
+ spin_lock(&bdev->glob->lru_lock);
+ drm_mm_debug_table(&man->manager, TTM_PFX);
+ spin_unlock(&bdev->glob->lru_lock);
+ }
}
static void ttm_bo_mem_space_debug(struct ttm_buffer_object *bo,
struct ttm_placement *placement)
{
- struct ttm_bo_device *bdev = bo->bdev;
- struct ttm_bo_global *glob = bo->glob;
- struct ttm_mem_type_manager *man;
int i, ret, mem_type;
printk(KERN_ERR TTM_PFX "No space for %p (%lu pages, %luK, %luM)\n",
@@ -106,10 +106,9 @@ static void ttm_bo_mem_space_debug(struct
ttm_buffer_object *bo,
&mem_type);
if (ret)
return;
- man = &bdev->man[mem_type];
printk(KERN_ERR TTM_PFX " placement[%d]=0x%08X (%d)\n",
i, placement->placement[i], mem_type);
- ttm_mem_type_manager_debug(glob, man);
+ ttm_mem_type_debug(bo->bdev, mem_type);
}
}
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: allow object creation to fallback to system ram
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: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_object.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 544e18f..43d63b5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -101,6 +101,12 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
INIT_LIST_HEAD(&bo->list);
radeon_ttm_placement_from_domain(bo, domain);
+ if ((domain & RADEON_GEM_DOMAIN_CPU) == 0) {
+ bo->placements[bo->placement.num_placement++] =
+ TTM_PL_MASK_CACHING |
+ TTM_PL_FLAG_SYSTEM;
+ bo->placement.num_busy_placement = bo->placement.num_placement;
+ }
/* Kernel allocation are uninterruptible */
r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
&bo->placement, 0, 0, !kernel, NULL, size,
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] radeon allow object creation to fallback to system ram
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 future. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 work on merging it. No excuses. Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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 > it merged into mainline. > > What the _hell_ is going on? Last time they were asked that, they wanted to be free of changing their kernel/userspace interface before upstreaming. Xav -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: Convert radeon to new ttm_bo_init
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/radeon/radeon_object.c
index 2040937..544e18f 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -56,25 +56,6 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object
*tbo)
kfree(bo);
}
-static inline u32 radeon_ttm_flags_from_domain(u32 domain)
-{
- u32 flags = 0;
-
- if (domain & RADEON_GEM_DOMAIN_VRAM) {
- flags |= TTM_PL_FLAG_VRAM | TTM_PL_FLAG_WC |
TTM_PL_FLAG_UNCACHED;
- }
- if (domain & RADEON_GEM_DOMAIN_GTT) {
- flags |= TTM_PL_FLAG_TT | TTM_PL_MASK_CACHING;
- }
- if (domain & RADEON_GEM_DOMAIN_CPU) {
- flags |= TTM_PL_FLAG_SYSTEM | TTM_PL_MASK_CACHING;
- }
- if (!flags) {
- flags |= TTM_PL_FLAG_SYSTEM | TTM_PL_MASK_CACHING;
- }
- return flags;
-}
-
void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 domain)
{
u32 c = 0;
@@ -100,7 +81,6 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
{
struct radeon_bo *bo;
enum ttm_bo_type type;
- u32 flags;
int r;
if (unlikely(rdev->mman.bdev.dev_mapping == NULL)) {
@@ -120,16 +100,16 @@ int radeon_bo_create(struct radeon_device *rdev, struct
drm_gem_object *gobj,
bo->surface_reg = -1;
INIT_LIST_HEAD(&bo->list);
- flags = radeon_ttm_flags_from_domain(domain);
+ radeon_ttm_placement_from_domain(bo, domain);
/* Kernel allocation are uninterruptible */
- r = ttm_buffer_object_init(&rdev->mman.bdev, &bo->tbo, size, type,
- flags, 0, 0, !kernel, NULL, size,
- &radeon_ttm_bo_destroy);
+ r = ttm_bo_init(&rdev->mman.bdev, &bo->tbo, size, type,
+ &bo->placement, 0, 0, !kernel, NULL, size,
+ &radeon_ttm_bo_destroy);
if (unlikely(r != 0)) {
if (r != -ERESTARTSYS)
dev_err(rdev->dev,
- "object_init failed for (%ld, 0x%08X)\n",
- size, flags);
+ "object_init failed for (%lu, 0x%08X)\n",
+ size, domain);
return r;
}
*bo_ptr = bo;
@@ -199,7 +179,7 @@ int radeon_bo_pin(struct radeon_bo *bo, u32 domain, u64
*gpu_addr)
radeon_ttm_placement_from_domain(bo, domain);
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i] |= TTM_PL_FLAG_NO_EVICT;
- r = ttm_buffer_object_validate(&bo->tbo, &bo->placement, false, false);
+ r = ttm_bo_validate(&bo->tbo, &bo->placement, false, false);
if (likely(r == 0)) {
bo->pin_count = 1;
if (gpu_addr != NULL)
@@ -223,7 +203,7 @@ int radeon_bo_unpin(struct radeon_bo *bo)
return 0;
for (i = 0; i < bo->placement.num_placement; i++)
bo->placements[i] &= ~TTM_PL_FLAG_NO_EVICT;
- r = ttm_buffer_object_validate(&bo->tbo, &bo->placement, false, false);
+ r = ttm_bo_validate(&bo->tbo, &bo->placement, false, false);
if (unlikely(r != 0))
dev_err(bo->rdev->dev, "%p validate failed for unpin\n", bo);
return r;
@@ -336,8 +316,7 @@ int radeon_bo_list_validate(struct list_head *head, void
*fence)
radeon_ttm_placement_from_domain(bo,
lobj->rdomain);
}
- r = ttm_buffer_object_validate(&bo->tbo,
- &bo->placement,
+ r = ttm_bo_validate(&bo->tbo, &bo->placement,
true, false);
if (unlikely(r))
return r;
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] TTM change buffer_object_init to use ttm_placement rather than flag
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 renamed ttm_buffer_object_init|validate to ttm_bo_init|validate this is shorter but also more consistent with others functions naming. For consistency i would like to rename struct ttm_buffer_object to struct ttm_bo but this lead to massive regular expression abuse for everyone using ttm so before proposing a patch let me know if you like or not this. I haven't strong feeling on that except that this would allow to stay in the 80 line lenght in some place. Cheers, Jerome -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/ttm: Convert ttm_buffer_object_init to use ttm_placement
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 second possible
placement. It also allow to create buffer in a specific range.
Also rename ttm_buffer_object_validate to ttm_bo_validate.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 130 ++---
include/drm/ttm/ttm_bo_api.h | 63 ++---
2 files changed, 87 insertions(+), 106 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c62818f..fc13f63 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1002,9 +1002,9 @@ static int ttm_bo_mem_compat(struct ttm_placement
*placement,
return -1;
}
-int ttm_buffer_object_validate(struct ttm_buffer_object *bo,
- struct ttm_placement *placement,
- bool interruptible, bool no_wait)
+int ttm_bo_validate(struct ttm_buffer_object *bo,
+ struct ttm_placement *placement,
+ bool interruptible, bool no_wait)
{
int ret;
@@ -1040,55 +1040,57 @@ int ttm_buffer_object_validate(struct ttm_buffer_object
*bo,
}
return 0;
}
-EXPORT_SYMBOL(ttm_buffer_object_validate);
+EXPORT_SYMBOL(ttm_bo_validate);
-int
-ttm_bo_check_placement(struct ttm_buffer_object *bo,
- uint32_t set_flags, uint32_t clr_flags)
+int ttm_bo_check_placement(struct ttm_buffer_object *bo,
+ struct ttm_placement *placement)
{
- uint32_t new_mask = set_flags | clr_flags;
-
- if ((bo->type == ttm_bo_type_user) &&
- (clr_flags & TTM_PL_FLAG_CACHED)) {
- printk(KERN_ERR TTM_PFX
- "User buffers require cache-coherent memory.\n");
- return -EINVAL;
- }
+ int i;
- if (!capable(CAP_SYS_ADMIN)) {
- if (new_mask & TTM_PL_FLAG_NO_EVICT) {
- printk(KERN_ERR TTM_PFX "Need to be root to modify"
- " NO_EVICT status.\n");
+ if (placement->fpfn || placement->lpfn) {
+ if (bo->mem.num_pages > (placement->lpfn - placement->fpfn)) {
+ printk(KERN_ERR TTM_PFX "Page number range to small "
+ "Need %lu pages, range is [%u, %u]\n",
+ bo->mem.num_pages, placement->fpfn,
+ placement->lpfn);
return -EINVAL;
}
-
- if ((clr_flags & bo->mem.placement & TTM_PL_MASK_MEMTYPE) &&
- (bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
- printk(KERN_ERR TTM_PFX
- "Incompatible memory specification"
- " for NO_EVICT buffer.\n");
- return -EINVAL;
+ }
+ for (i = 0; i < placement->num_placement; i++) {
+ if (!capable(CAP_SYS_ADMIN)) {
+ if (placement->placement[i] & TTM_PL_FLAG_NO_EVICT) {
+ printk(KERN_ERR TTM_PFX "Need to be root to "
+ "modify NO_EVICT status.\n");
+ return -EINVAL;
+ }
+ }
+ }
+ for (i = 0; i < placement->num_busy_placement; i++) {
+ if (!capable(CAP_SYS_ADMIN)) {
+ if (placement->busy_placement[i] &
TTM_PL_FLAG_NO_EVICT) {
+ printk(KERN_ERR TTM_PFX "Need to be root to "
+ "modify NO_EVICT status.\n");
+ return -EINVAL;
+ }
}
}
return 0;
}
-int ttm_buffer_object_init(struct ttm_bo_device *bdev,
- struct ttm_buffer_object *bo,
- unsigned long size,
- enum ttm_bo_type type,
- uint32_t flags,
- uint32_t page_alignment,
- unsigned long buffer_start,
- bool interruptible,
- struct file *persistant_swap_storage,
- size_t acc_size,
- void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init(struct ttm_bo_device *bdev,
+ struct ttm_buffer_object *bo,
+ unsigned long size,
+ enum ttm_bo_type type,
+ struct ttm_placement *placement,
+ uint32_t page_alignment,
+ unsigned long buffer_start,
+ bool interruptible,
+ struct file *persistant_sw
Re: PROBLEM: radeon, kernel => 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen
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;h=b27b63750d912e80d61d2120c4a1664062d0f808 Alex > Best, > Viktor > > On Tuesday 08 December 2009 04:54:35 pm Alex Deucher wrote: >> On Wed, Dec 2, 2009 at 7:51 AM, Viktor Malyarchuk wrote: >> > Hi Alex, >> > >> > I bisected drm-next branch from Dave's git tree >> > git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git . >> > >> > The result is: >> > >> > ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff is the first bad commit >> > commit ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff >> > Author: Alex Deucher >> > Date: Fri Oct 16 11:15:25 2009 -0400 >> > >> > drm/radeon/kms/atom: add support for spread spectrum (v2) >> > >> > Spread spectrum is a periodic disturbance added >> > to the feedback divider to change the pixel clock >> > periodically to reduce interference. >> > >> > Only enabled on LVDS. >> > >> > v2: add support for r4xx and fix DCE 3 >> > >> > Signed-off-by: Alex Deucher >> > Signed-off-by: Dave Airlie >> > >> > :04 04 4cd7bdabeac245accf789e26e944aeb678fe1f16 >> > >> > 077d0d318aed2f25464f9eeaffa39f33fa652909 M drivers >> >> Can you try the patch I attached to bug 25506: >> http://bugs.freedesktop.org/show_bug.cgi?id=25506 >> >> Alex >> >> > Best, >> > Viktor >> > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
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? Linus -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Fix printk format & compute bo->mem.size at bo initialization
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.c
@@ -80,7 +80,7 @@ static void ttm_mem_type_manager_debug(struct ttm_bo_global
*glob,
printk(KERN_ERR TTM_PFX "gpu_offset: 0x%08lX\n", man->gpu_offset);
printk(KERN_ERR TTM_PFX "io_offset: 0x%08lX\n", man->io_offset);
printk(KERN_ERR TTM_PFX "io_size: %ld\n", man->io_size);
- printk(KERN_ERR TTM_PFX "size: %ld\n", (unsigned long)man->size);
+ printk(KERN_ERR TTM_PFX "size: %llu\n", man->size);
printk(KERN_ERR TTM_PFX "available_caching: 0x%08X\n",
man->available_caching);
printk(KERN_ERR TTM_PFX "default_caching: 0x%08X\n",
@@ -98,7 +98,7 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object
*bo,
struct ttm_mem_type_manager *man;
int i, ret, mem_type;
- printk(KERN_ERR TTM_PFX "No space for %p (%ld pages, %ldK, %ldM)\n",
+ printk(KERN_ERR TTM_PFX "No space for %p (%lu pages, %luK, %luM)\n",
bo, bo->mem.num_pages, bo->mem.size >> 10,
bo->mem.size >> 20);
for (i = 0; i < placement->num_placement; i++) {
@@ -,6 +,7 @@ int ttm_buffer_object_init(struct ttm_bo_device *bdev,
bo->glob = bdev->glob;
bo->type = type;
bo->num_pages = num_pages;
+ bo->mem.size = num_pages << PAGE_SHIFT;
bo->mem.mem_type = TTM_PL_SYSTEM;
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
--
1.6.5.2
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25544] KMS/R200: CS section size missmatch start at (r200_state_init.c,tex_emit_mm,703) 5 vs 9
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 the two physical texture units on r200. Well, in fact there shouldn't be any differences due to that, but there are hardware bugs so need to emit state for texture units 0/1 pairwise (these workarounds are insufficient btw at least when using ati_fragment_shader, but that's another story). I think there's an issue in the current code if neither a texture is bound to a unit, nor is it really enabled, in this case it will try to subtract the dwords it doesn't need for relocation twice, which can only happen with r200 (on rv250 it would never submit the state for this texture unit in the first place). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
http://bugs.freedesktop.org/show_bug.cgi?id=2 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
http://bugs.freedesktop.org/show_bug.cgi?id=2 Alec Habig changed: What|Removed |Added CC||aha...@umn.edu --- Comment #11 from Alec Habig 2009-12-10 06:24:37 PST --- With the same hardware, I get a segfault, as detailed in bug 25281. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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 properly? > Hey, this is a good news!! It works!!! I've switched to Gnome and executed it and it works. So now I've the problem just in KDE, should it work as well with Kwin. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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 bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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 > enabled > in the X server, but KDE is refusing to enabling its own compositing manager. > > I'm not so sure... Unlucky I've the same problem in Gnome that use Compiz for the compositing. Any idea how to find the right components that has the problem? I'd like to open a bug to right group... or do you advice anyay to start with kde? Thanks again Antenore -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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, but KDE is refusing to enabling its own compositing manager. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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 reverted to their previous values. Check your X configuration. You may also consider changing advanced options, especially changing the compositing type. Enclosed you have the xdpyinfo log Thanks again Antenore -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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 --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25555] No compositing with firegl v5200
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 'xdpyinfo'. Adam -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23106] mplayer -vo gl:yuv=6 segfaults r300_state.c:r300SetupTextures() (mesa-7.5)
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 assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Check module arguments to be valid
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 here and prints > > radeon :06:00.0: vram limit (0) must be a power of 2 > radeon :06:00.0: invalida AGP mode 0 (valid mode: -1, 1, 2, 4, 8) > > on a PCIE box with no params specified. > > Dave. > Oups forget the noparam case ... Cheers, Jerome -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25478] SIGSEGV in radeon_texture.c:524
http://bugs.freedesktop.org/show_bug.cgi?id=25478 Fabio changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Fabio 2009-12-10 00:48:26 PST --- Patch was applied in 7.7 branch and master. *** This bug has been marked as a duplicate of bug 25355 *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25355] sauerbraten segfaults after 63c00c53a3019b801c5eee8a12f7862422f79f10
http://bugs.freedesktop.org/show_bug.cgi?id=25355 Fabio changed: What|Removed |Added CC||david.ro...@mcgill.ca --- Comment #4 from Fabio 2009-12-10 00:48:26 PST --- *** Bug 25478 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
