FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 11-30-2009, 11:57 PM
Steve Conklin
 
Default Nouveau information and proposed plan

This email summarizes a discussion that took place on #ubuntu-x IRC, and
the tentative plan that was arrived at. The IRC discussion is attached
for reference.

First, there was a discussion of what is required in order to bring
Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
which looks like it amounts to over 500 patches right now. This
presents a major issue for the kernel team, in how to manage that.

Looking at the Fedora 12 patch set, there is a 2.9M drm-next patch.

Assuming resolution of that issue[*], here's a tentative plan for
proceeding with Nouveau:

* We pull Nouveau and the required drm changes into karmic ASAP
* We invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
* We also decide at that point whether to rebase to a more recent nouveau or to freeze and take selected patches through the release.

It is a bit of a tight schedule to get this into A1, since freeze is in one week.

There was also a discussion of risks vs. benefits of going to Nouveau, see the attached log.
[*] I defer to Andy and Tim. Backporting the entire drm-next
tree seems risky to me. I'd like some discussion - perhaps at
tomorrow's kernel team meeting.

Steve


(05:32:28 PM) sconklin: heya
(05:32:33 PM) RAOF: Howdie.
(05:32:51 PM) bryce: sconklin, we were just discussing kernel stuff needed for -nouveau/kms (and radeon kms)
(05:33:12 PM) bryce: in particular, it appears to need drm-next
(05:33:23 PM) bryce: sconklin, <RAOF> Here's a list of git commits for nouveau http://pastebin.com/f5c80954e
(05:33:27 PM) jcristau: RAOF: shouldn't be too hard to extract just what nouveau needs from -next
(05:33:31 PM) RAOF: So, getting nouveau in the kernel by merging from their kernel tree implies merging in drm-next, because they frequently merge drm-next into their tree.
(05:33:43 PM) jcristau: wel, hopefully
(05:33:58 PM) jcristau: +l
(05:35:10 PM) RAOF: If we want to add nouveau by means of a mega-patch we'll need to carefully merge in the drm changes nouveau requires, and check that they don't break our other drm drivers.
(05:35:43 PM) sconklin: Someone told me that the drm-next commits required for nouveau were not stable with intel harwdare, anyone know about that? It was a hallway conversation at UDS
(05:36:16 PM) RAOF: I don't know about that, no.
(05:36:25 PM) bryce: jbarnes, ^^ ?
(05:36:37 PM) tormod: radeon KMS will probably need some drm-next stuff also
(05:37:05 PM) sconklin: here's my general thinking about all of this - please say something if I'm on crack . . .
(05:37:25 PM) RAOF: If we want to test drm-next I can trivially extend nouveau-kernel-source to build the other drm drivers, too.
(05:37:35 PM) sconklin: I'm beginning to understand the risks to nouveau, and there are a lot of them, and it also impacts our normal code flow.
(05:37:57 PM) sconklin: The best thing would be to get it into the first alpha and see if it falls over.
(05:38:38 PM) sconklin: I still don't have a solid understanding of what our benefits are as a distro to using nouveau
(05:38:52 PM) sconklin: I do understand the benefits to nouveau.
(05:39:21 PM) sconklin: I also see that Fedora appears to be dealing with a pile of graphics stability issues rigth now
(05:39:27 PM) bryce: sconklin, one of the main benefits we gain is a more active upstream (compared with -nv)
(05:39:55 PM) bryce: (and I admit "active upstream" can be a con as well as a pro depending on the situation...)
(05:40:03 PM) sconklin: bryce: understood, but that upstream pretty much admits that they aren't ready for relases or a distro.
(05:40:29 PM) sconklin: But . . . this could really get them some huge benefits also
(05:40:36 PM) RAOF: Which is a pity, because they're a much better nvidia driver than nv.
(05:40:48 PM) jcristau: didn't stop fedora. but then rh hired one of the nouveau developers.
(05:41:29 PM) bryce: sconklin, I still expect that most nvidia owners will still just use -nouveau as a bridge to installing -nvidia.
(05:41:36 PM) sconklin: yeah, and trust me I know that "because Fedora does/doesn't do something" isn't a good reason to go either way on a decision.
(05:42:05 PM) jcristau: fair enough
(05:42:17 PM) jk- [n=jk@ppp121-45-209-104.lns20.cbr1.internode.on.net] entered the room.
(05:42:18 PM) RAOF: bryce: I agree. Nouveau is a much better 2d driver, but most people are going to want 3d.
(05:42:20 PM) sconklin: bryce, and are all the drm bits either compatible or selectable between -nouveau and -nvidia?
(05:42:24 PM) tormod: what RHEL will do is maybe more relevant
(05:42:43 PM) RAOF: nvidia doesn't have any drm bits.
(05:42:47 PM) jcristau: sconklin: nvidia doesn't use drm at all
(05:42:58 PM) sconklin: tormod: not necessarily - RHEL and Ubuntu have very different user bases.
(05:43:04 PM) bryce: sconklin, nvidia does its own thing
(05:43:17 PM) RAOF: A problem nouveau _may_ introduce is binding to the hardware in the initramfs and preventing nvidia's kernel module from loading. I haven't tested that.
(05:43:30 PM) jbarnes: bryce, sconklin: I haven't heard anything about that either
(05:43:31 PM) sconklin: bryce: sorry, I meant "any of the things in drm-next"
(05:43:41 PM) jbarnes: nouveau and intel should be mostly independent in the kernel
(05:43:42 PM) bryce: sconklin, ahh
(05:44:23 PM) sconklin: ok I think I drifted off topic a little.
(05:44:39 PM) RAOF: jbarnes: But nouveau requires a different drm.ko to the one we ship, and that's shared.
(05:44:52 PM) sconklin: bryce: the ptches that you pastebin'd - is that the entire drm-next diff from our tree?
(05:45:20 PM) jbarnes: RAOF: yeah but it's mainly TTM functionality there afaik
(05:45:23 PM) bryce: RAOF, sconklin, so really what -nouveau buys us is an out-of-the-box kms 2D experience on first boot (ooh nice boot), followed by installation of -nvidia and the usual teeth grinding on binary blobs ;-)
(05:45:28 PM) jbarnes: unless they've also made some core mode setting changes or something
(05:45:53 PM) bryce: sconklin, no I think RAOF selected the specific ones needed. RAOF?
(05:45:59 PM) RAOF: sconklin: It's the full diff of everything nouveau touches against our tree.
(05:46:06 PM) sconklin: bryce, RAOF - plus we support open development, and provide some solid testing base and bug reporting for upstream.
(05:46:34 PM) RAOF: sconklin: Upstream will unlikely to be terribly interested in our bugs, unless we track git closely.
(05:46:52 PM) tormod: don't tell Bryce there will be more bug reports :P
(05:47:03 PM) bryce: sconklin, right, and while in the near term you're right that this is to upstream's benefit mostly, since it's an LTS it hopefully means in the long term we'll be more able to deploy more fixes than if we stuck with -nv
(05:47:14 PM) sconklin: RAOF: I intend to offer them the option of linking with lp through the upstream plugin, they probably won't want to.
(05:47:45 PM) bryce: although that's kind of hand-wavy... -nouveau is developing fast enough that I suspect backporting fixes to the LTS would only be realistic for some months before the codebases are too divergent.
(05:48:40 PM) sconklin: bryce: right. and I can forsee a degenerate situation where we end up sort of stuck with the LTS, but the testing we did there lets us turn our a really good M release
(05:48:44 PM) ripps [n=ripps@68-191-145-39.dhcp.dlth.mn.charter.com] entered the room.
(05:48:57 PM) RAOF: bryce: I support that assessment, although the bottleneck would be the kernel, rather than libdrm (because that's much more nicely isolated)
(05:49:50 PM) sconklin: Yes, what I was describing was the kernel. But also remember this - that starting with Lucid we'll probably also have the ability to run later kernels on Lucid userspace
(05:49:52 PM) RAOF: We could track git closely in xorg-edgers and require bug reporters to retry with that; upstream would likely be interested in _those_ bugs.
(05:50:07 PM) sconklin: which gives people a choice
(05:50:40 PM) sconklin: so I'd like to propose a plan (for the kernel at least)
(05:51:13 PM) sconklin: That we (very soon) pull nouveau and the required drm-next into Lucid.
(05:51:56 PM) sconklin: That we invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
(05:52:21 PM) sconklin: and whether to rebase to a more recent nouveau or to freeze and take selected patches.
(05:52:55 PM) sconklin: If we freeze, then there's a good chance that by the time Lucid releases, linus's tree will have caught up with the drm-next that was used for nouveau.
(05:52:56 PM) bryce: sconklin, +1 sounds good to me
(05:53:24 PM) RAOF: +1 from me, too.
(05:53:32 PM) sconklin: and we'll just be supporting nouveau + selected patches, without any drm sync problems.
(05:54:21 PM) sconklin: ok, I'll write this up and send it around to the kernel group (and who else) - and which mailing lists am I not on that I need to be? - X related?
(05:54:41 PM) tormod: linus's tree catch up with drm-next, isn't that 2.6.33 by definition?
(05:54:54 PM) jcristau: tormod: rc1
(05:55:15 PM) tormod: and lucid has settled for 2.6.32 right
(05:55:19 PM) sconklin: yeah, I think that's right.
(05:55:24 PM) sconklin: so we won't get it.
(05:55:51 PM) bryce: sconklin, ubuntu-x@lists.ubuntu.com
(05:55:53 PM) sconklin: I would say here that pulling in drm-next is subject to veto by the kernel ack process
(05:56:06 PM) sconklin: s/would/should/
(05:56:17 PM) sconklin: I can't make those decisions unilaterally
(05:56:30 PM) RAOF: I wouldn't expect as much.
(05:56:45 PM) sconklin: No, just trying to be clear
(05:57:13 PM) tormod: I wonder about alpha-1 that's like next week, right. shouldn't this be dogfood for at least a week? sounds like sorting out the right drm-next commits is not trivial
(05:57:35 PM) sconklin: so I'll join the ubuntu-x list and then send this to both that and the kernel list, and shout if I get anything wrong, please
(05:58:29 PM) sconklin: tormod: I know, and I'm getting beat up about some other unrelated things at the moment, so let me discuss the priorities with some people and see if I can get some help
(05:58:38 PM) tormod: you'll get broad coverage but maybe more than you'd like
(06:00:19 PM) bryce: tormod, alpha-1 is dec 10th
(06:00:30 PM) sconklin: I've seen a number of opinions that graphics got worse from Jaunty->Karmic, I don't want to set up any sort of trend. And also, there are people irate over Fedora because 3d support is not good, but no one really tested 3d until after the release, and I think we'll see the same thing happen.
(06:00:41 PM) tormod: bryce, which means freeze on 8th
(06:00:48 PM) bryce: tormod, right
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-01-2009, 01:43 PM
Andy Whitcroft
 
Default Nouveau information and proposed plan

On Mon, Nov 30, 2009 at 06:57:58PM -0600, Steve Conklin wrote:
> This email summarizes a discussion that took place on #ubuntu-x IRC, and
> the tentative plan that was arrived at. The IRC discussion is attached
> for reference.
>
> First, there was a discussion of what is required in order to bring
> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
> which looks like it amounts to over 500 patches right now. This
> presents a major issue for the kernel team, in how to manage that.
>
> Looking at the Fedora 12 patch set, there is a 2.9M drm-next patch.
>
> Assuming resolution of that issue[*], here's a tentative plan for
> proceeding with Nouveau:
>
> * We pull Nouveau and the required drm changes into karmic ASAP
> * We invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
> * We also decide at that point whether to rebase to a more recent nouveau or to freeze and take selected patches through the release.
>
> It is a bit of a tight schedule to get this into A1, since freeze is in one week.
>
> There was also a discussion of risks vs. benefits of going to Nouveau, see the attached log.
>
>[*] I defer to Andy and Tim. Backporting the entire drm-next
> tree seems risky to me. I'd like some discussion - perhaps at
> tomorrow's kernel team meeting.

Ok. A few comments. The first is that at 2.9MB the drm-next update
is just too big to be safe for general consumption, the risk to
other drm users such as i915 and ATI radeon would be high, are we are
meant to be more risk averse than normal for Lucid. We likely have
a couple of options. The first might be to rename the updated drm ->
drm-next. The simpler and likely sanest approach would be to have a
linux-backports-modules-nouveau which contains the updated drm stack and
nouveau driver. Jockey and the installer should be able to bridge the
gap there.

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-01-2009, 07:33 PM
"Luis R. Rodriguez"
 
Default Nouveau information and proposed plan

On Tue, Dec 1, 2009 at 6:43 AM, Andy Whitcroft <apw@canonical.com> wrote:
> On Mon, Nov 30, 2009 at 06:57:58PM -0600, Steve Conklin wrote:
>> This email summarizes a discussion that took place on #ubuntu-x IRC, and
>> the tentative plan that was arrived at. The IRC discussion is attached
>> for reference.
>>
>> First, there was a discussion of what is required in order to bring
>> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
>> which looks like it amounts to over 500 patches right now. This
>> presents a major issue for the kernel team, in how to manage that.
>>
>> Looking at the Fedora 12 patch set, there is a 2.9M drm-next patch.
>>
>> Assuming resolution of that issue[*], here's a tentative plan for
>> proceeding with Nouveau:
>>
>> * We pull Nouveau and the required drm changes into karmic ASAP
>> * We invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
>> * We also decide at that point whether to rebase to a more recent nouveau or to freeze and take selected patches through the release.
>>
>> It is a bit of a tight schedule to get this into A1, since freeze is in one week.
>>
>> There was also a discussion of risks vs. benefits of going to Nouveau, see the attached log.
>>
>>[*] I defer to Andy and Tim. Backporting the entire drm-next
>> tree seems risky to me. I'd like some discussion - perhaps at
>> tomorrow's kernel team meeting.
>
> Ok. *A few comments. *The first is that at 2.9MB the drm-next update
> is just too big to be safe for general consumption, the risk to
> other drm users such as i915 and ATI radeon would be high, are we are
> meant to be more risk averse than normal for Lucid. *We likely have
> a couple of options. *The first might be to rename the updated drm ->
> drm-next. *The simpler and likely sanest approach would be to have a
> linux-backports-modules-nouveau which contains the updated drm stack and
> nouveau driver.

I'm interested in seeing more compat code being shared and stuffed
together to avoid re-inventing the wheel. We may soon backport
bluetooth for example and share a compat.ko for both bluetooth and
802.11. I know nothing about video though but do wonder if anything
from this same compat.ko could be useful to a possible video-backport
effort. So alsa had its own backport package, do the video guys do any
backports or would this have to be done from scratch?

> *Jockey and the installer should be able to bridge the
> gap there.

What if linux-next was just made available as an optional kernel for
users who wanted to test it? This would not in any way resolve the
userspace option though.

Luis

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-02-2009, 02:21 AM
Christopher James Halse Rogers
 
Default Nouveau information and proposed plan

On Tue, 2009-12-01 at 14:43 +0000, Andy Whitcroft wrote:
> On Mon, Nov 30, 2009 at 06:57:58PM -0600, Steve Conklin wrote:
> > This email summarizes a discussion that took place on #ubuntu-x IRC, and
> > the tentative plan that was arrived at. The IRC discussion is attached
> > for reference.
> >
> > First, there was a discussion of what is required in order to bring
> > Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
> > which looks like it amounts to over 500 patches right now. This
> > presents a major issue for the kernel team, in how to manage that.
> >
> > Looking at the Fedora 12 patch set, there is a 2.9M drm-next patch.
> >
> > Assuming resolution of that issue[*], here's a tentative plan for
> > proceeding with Nouveau:
> >
> > * We pull Nouveau and the required drm changes into karmic ASAP
> > * We invest in heavy testing at alpha 1 and alpha 2, and give ourselves the chance to make an assessment after A1 whether to continue.
> > * We also decide at that point whether to rebase to a more recent nouveau or to freeze and take selected patches through the release.
> >
> > It is a bit of a tight schedule to get this into A1, since freeze is in one week.
> >
> > There was also a discussion of risks vs. benefits of going to Nouveau, see the attached log.
> >
> >[*] I defer to Andy and Tim. Backporting the entire drm-next
> > tree seems risky to me. I'd like some discussion - perhaps at
> > tomorrow's kernel team meeting.
>
> Ok. A few comments. The first is that at 2.9MB the drm-next update
> is just too big to be safe for general consumption, the risk to
> other drm users such as i915 and ATI radeon would be high, are we are
> meant to be more risk averse than normal for Lucid. We likely have
> a couple of options. The first might be to rename the updated drm ->
> drm-next. The simpler and likely sanest approach would be to have a
> linux-backports-modules-nouveau which contains the updated drm stack and
> nouveau driver. Jockey and the installer should be able to bridge the
> gap there.
What would be the cost/benefit here over the current
nouveau-kernel-source source, built with dkms?
The ones I can think of are:

pros:
*) Users do not need kernel headers installed
*) Fewer packaging variables; we know the exact kernel version nouveau
+drm needs to build against.

cons:
*) Update skew - the nouveau DDX doesn't handle a missing drm module
with any degree of aplomb, and it's not possible to ensure that a
linux-backport-modules-nouveau package for the currently running kernel
ABI is installed. This is also a problem for the current
nouveau-kernel-source package, but I think it's a bit easier to ensure
that the right kernel headers get installed.

Another option would be to see what needs to be done to nouveau to make
it work on our current drm. There didn't seem to be a *huge* diffstat
between our current drm/ttm and what nouveau uses. I'm not wild about
this idea, though.
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-07-2009, 10:51 PM
Christopher James Halse Rogers
 
Default Nouveau information and proposed plan

On Mon, 2009-11-30 at 18:57 -0600, Steve Conklin wrote:
> This email summarizes a discussion that took place on #ubuntu-x IRC, and
> the tentative plan that was arrived at. The IRC discussion is attached
> for reference.
>
> First, there was a discussion of what is required in order to bring
> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
> which looks like it amounts to over 500 patches right now. This
> presents a major issue for the kernel team, in how to manage that.

I have been talking with Ben Skeggs (darktama on freenode) the nouveau
dev paid by Red Hat, who is also deciding what to do about updating
nouveau in Fedora rawhide.

He thinks that the nouveau kernel module should work against the stock
2.6.32 drm tree, so I tried copying drivers/gpu/drm/nouveau and
associated headers into the lucid kernel tree, the results of which are
in the nouveau-scratchpad branch of
http://cooperteam.net/lucid-kernel-nouveau.git . The only changes
outside of the nouveau-specific directories are hooking up the Kconfig &
Makefiles, and exporting 4 extra symbols from ttm.ko.

I've tested the resulting kernel on my laptop with a geforce 7600go; it
works as far as I've tested - kms on boot, video playback, metacity
compositing. The only thing that failed was suspend, but this laptop
wasn't suspending correctly with the out-of-tree nouveau modules,
either, nor with nv.

It might be easier to incorporate nouveau into the Lucid kernel than I
thought.
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-07-2009, 11:07 PM
Christopher James Halse Rogers
 
Default Nouveau information and proposed plan

On Mon, 2009-11-30 at 18:57 -0600, Steve Conklin wrote:
> This email summarizes a discussion that took place on #ubuntu-x IRC, and
> the tentative plan that was arrived at. The IRC discussion is attached
> for reference.
>
> First, there was a discussion of what is required in order to bring
> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
> which looks like it amounts to over 500 patches right now. This
> presents a major issue for the kernel team, in how to manage that.

I have been talking with Ben Skeggs (darktama on freenode) the nouveau
dev paid by Red Hat, who is also deciding what to do about updating
nouveau in Fedora rawhide.

He thinks that the nouveau kernel module should work against the stock
2.6.32 drm tree, so I tried copying drivers/gpu/drm/nouveau and
associated headers into the lucid kernel tree, the results of which are
in the nouveau-scratchpad branch of
http://cooperteam.net/lucid-kernel-nouveau.git . The only changes
outside of the nouveau-specific directories are hooking up the Kconfig &
Makefiles, and exporting 4 extra symbols from ttm.ko.

I've tested the resulting kernel on my laptop with a geforce 7600go; it
works as far as I've tested - kms on boot, video playback, metacity
compositing. The only thing that failed was suspend, but this laptop
wasn't suspending correctly with the out-of-tree nouveau modules,
either, nor with nv.

It might be easier to incorporate nouveau into the Lucid kernel than I
thought.

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-08-2009, 04:28 PM
"Luis R. Rodriguez"
 
Default Nouveau information and proposed plan

On Mon, Dec 7, 2009 at 4:07 PM, Christopher James Halse Rogers
<raof@ubuntu.com> wrote:
> On Mon, 2009-11-30 at 18:57 -0600, Steve Conklin wrote:
>> This email summarizes a discussion that took place on #ubuntu-x IRC, and
>> the tentative plan that was arrived at. The IRC discussion is attached
>> for reference.
>>
>> First, there was a discussion of what is required in order to bring
>> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
>> which looks like it amounts to over 500 patches right now. This
>> presents a major issue for the kernel team, in how to manage that.
>
> I have been talking with Ben Skeggs (darktama on freenode) the nouveau
> dev paid by Red Hat, who is also deciding what to do about updating
> nouveau in Fedora rawhide.
>
> He thinks that the nouveau kernel module should work against the stock
> 2.6.32 drm tree, so I tried copying drivers/gpu/drm/nouveau and
> associated headers into the lucid kernel tree, the results of which are
> in the nouveau-scratchpad branch of
> http://cooperteam.net/lucid-kernel-nouveau.git . *The only changes
> outside of the nouveau-specific directories are hooking up the Kconfig &
> Makefiles, and exporting 4 extra symbols from ttm.ko.

Which exported symbols are those and what other new video drivers use
from the 2.6.32 drm tree?

> I've tested the resulting kernel on my laptop with a geforce 7600go; it
> works as far as I've tested - kms on boot, video playback, metacity
> compositing. *The only thing that failed was suspend, but this laptop
> wasn't suspending correctly with the out-of-tree nouveau modules,
> either, nor with nv.
>
> It might be easier to incorporate nouveau into the Lucid kernel than I
> thought.

I was just sent a patch to add more backport stuff to compat-wireless
for bluetooth so we can also carry new bluetooth changes on older
kernels. This won't seem too important until we get users wanting to
use BT 3.0 which requires hand off coordination with 802.11. We are
likely to support this on older kernels so will be supporting
backports of both the bluetooth stack and 802.11 down to 2.6.27 within
the same package but with now a generic compat.ko module. Although I
wouldn't expect video to be backported down to 2.6.27 if you just
needed 4 symbols to get the kernel drivers compiled I could just stuff
those into the generic compat tree I'm working on:

http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat.git;a=summary

If ubuntu packages again compat-wireless for Lucid this would mean
having these symbols available through a generic compat module, and if
those symbols could be used by other video drivers it would also allow
backporting of those as well.

Luis

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-08-2009, 04:44 PM
Tim Gardner
 
Default Nouveau information and proposed plan

Luis R. Rodriguez wrote:
..snip..

> If ubuntu packages again compat-wireless for Lucid this would mean
> having these symbols available through a generic compat module, and if
> those symbols could be used by other video drivers it would also allow
> backporting of those as well.
>

I expect we _will_ be packaging for Lucid a 2.6.33 based compat-wireless
stable (when its ready).

rtg

--
Tim Gardner tim.gardner@canonical.com

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-08-2009, 05:28 PM
"Luis R. Rodriguez"
 
Default Nouveau information and proposed plan

On Tue, Dec 8, 2009 at 9:44 AM, Tim Gardner <tim.gardner@canonical.com> wrote:
> Luis R. Rodriguez wrote:
> ..snip..
>
>> If ubuntu packages again compat-wireless for Lucid this would mean
>> having these symbols available through a generic compat module, and if
>> those symbols could be used by other video drivers it would also allow
>> backporting of those as well.
>>
>
> I expect we _will_ be packaging for Lucid a 2.6.33 based compat-wireless
> stable (when its ready).

Ok thanks for the heads up. Bluetooth *might* bundled together there
as well, still working on the details.

In this case if we stuff those 4 symbols in could go into compat.ko.
I'd even consider stuffing Nouveau but am not sure of the other module
dependencies that this has. Is just upgrading the
drivers/gpu/drm/nouveau module sufficient? What about the drm modules?
What about a backport of radeon as well? In any case I'll likely start
basing my compat stuff off of linux-next which should get me not only
wireless-testing but also b44 updates as well as bluetooth (and if
this approach is welcomed maybe video).

Luis

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 12-08-2009, 10:48 PM
Christopher James Halse Rogers
 
Default Nouveau information and proposed plan

On Tue, 2009-12-08 at 09:28 -0800, Luis R. Rodriguez wrote:
> On Mon, Dec 7, 2009 at 4:07 PM, Christopher James Halse Rogers
> <raof@ubuntu.com> wrote:
> > On Mon, 2009-11-30 at 18:57 -0600, Steve Conklin wrote:
> >> This email summarizes a discussion that took place on #ubuntu-x IRC, and
> >> the tentative plan that was arrived at. The IRC discussion is attached
> >> for reference.
> >>
> >> First, there was a discussion of what is required in order to bring
> >> Nouveau into our kernel. Nouveau brings in the entire drm-next tree,
> >> which looks like it amounts to over 500 patches right now. This
> >> presents a major issue for the kernel team, in how to manage that.
> >
> > I have been talking with Ben Skeggs (darktama on freenode) the nouveau
> > dev paid by Red Hat, who is also deciding what to do about updating
> > nouveau in Fedora rawhide.
> >
> > He thinks that the nouveau kernel module should work against the stock
> > 2.6.32 drm tree, so I tried copying drivers/gpu/drm/nouveau and
> > associated headers into the lucid kernel tree, the results of which are
> > in the nouveau-scratchpad branch of
> > http://cooperteam.net/lucid-kernel-nouveau.git . The only changes
> > outside of the nouveau-specific directories are hooking up the Kconfig &
> > Makefiles, and exporting 4 extra symbols from ttm.ko.
>
> Which exported symbols are those and what other new video drivers use
> from the 2.6.32 drm tree?
>
The symbols are:
ttm_bo_wait_unreserved
ttm_bo_wait_cpu
ttm_bo_synccpu_write_grab
ttm_bo_synccpu_write_release

None of the other drm drivers in the 2.6.32 tree use these symbols,
although it's possible that a more recent radeon drm would; I'm not
familiar with the radeon world.
--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 09:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org