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 02-17-2010, 07:15 PM
Andy Whitcroft
 
Default Status of kernel X drivers

We have been chatting on and off in various forums about the state of the
X drivers in the kernel, and it seemed time to get that discussion out
onto the lists.

The main question is really: "Are the drivers in v2.6.32 going to be
supportable for the LTS?". This has been triggered by a strong upstream
response of "That sounds like something we already fixed in 2.6.33, use
that instead." to bugs we find in v2.6.32, this has been across all the
graphics drivers.

There seem to be a number of options here:

Option 1 -- stick with v2.6.32: taking stable updates, backporting fixes
and hardware enablement on a individually. Using blacklisting where
appropriate to alieviate symptoms,

Option 2 -- backport v2.6.33 drm: pulling back the v2.6.33 wholesale
as that is where the developers are working, and

Option 3 -- produce an LBM backport for drm: pulling back updates for
drm wholesale for opt-in use; effectivly in combination with #1.

Each of these have their own issues, and here I am trying to summarise
the collective wisdom on these.

Option 1: here we have the advantage that there is work ongoing in the
-stable team pulling back and validating fixes for this release, this is
expected to continue for the long term as v2.6.32 has been announced as
long term support. This most closely fits the LTS model but is likely to
have issues for cards at release which will need testing and managing.

Option 2: although we may have less issues at the outset, we are inevitably
going to end up with the same issue that 2.6.33 is no longer interesting
and 2.6.34 is where development is going on; we end up at (1) before long.
This is also high risk as we expose all users to this new code whether
they would have a reasonable experience currently.

Option 3: here we have the work of trying to maintain the v2.6.32
versions of the drivers, but can optionally defer backporting invasive
changes by pushing the affected users to the backport. We do however
end up needing the X userspace to handle the DRM skew between the main
kernel and the backport.

Certainly for me option 3 seems the most appropriate here. We work the
kernel in our normal process, we maintain no major skew in that kernel
providing a low-risk base. The backports provides the safety valve for
the more invasive fixes and hardware enablement. We backport what is
sensible and safe, and where it is simply not practicle it goes into the
LBM module.

This however does place some effort on the X-team, and we would like to
start discussion on whether this seems sensible and maintainable from the
X side. For this to work, we would likely need to have X-server support
for both the v2.6.32 drm stack and the v2.6.33 drm (and possibly later)
stack. I have heard that it _may_ be possible to serve both of these
kernel stacks from the same userspace? Does the X-team think that the
current userspace bits are likely to be able to handle this level of skew?
Or if it is not do we think its practicle to try and handle it this way?
As I understand things we will have some v2.6.33 support required
for the current Nouveau plans so we may have to do this work anyhow?

Anyhow I put this out there to start discussion.

Comments? Ideas? Feedback?

-apw

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 12:50 AM
Bryce Harrington
 
Default Status of kernel X drivers

[Forwarding to ubuntu-x@ apw's summary of some discussions we've been
having.]

We have been chatting on and off in various forums about the state of
the X drivers in the kernel, and it seemed time to get that discussion
out onto the lists.

The main question is really: "Are the drivers in v2.6.32 going to be
supportable for the LTS?". This has been triggered by a strong upstream
response of "That sounds like something we already fixed in 2.6.33, use
that instead." to bugs we find in v2.6.32, this has been across all the
graphics drivers.

There seem to be a number of options here:

Option 1 -- stick with v2.6.32: taking stable updates, backporting fixes
and hardware enablement on a individually. Using blacklisting where
appropriate to alieviate symptoms,

Option 2 -- backport v2.6.33 drm: pulling back the v2.6.33 wholesale
as that is where the developers are working, and

Option 3 -- produce an LBM backport for drm: pulling back updates for
drm wholesale for opt-in use; effectivly in combination with #1.

Each of these have their own issues, and here I am trying to summarise
the collective wisdom on these.

Option 1: here we have the advantage that there is work ongoing in the
-stable team pulling back and validating fixes for this release, this is
expected to continue for the long term as v2.6.32 has been announced as
long term support. This most closely fits the LTS model but is likely
to have issues for cards at release which will need testing and
managing.

Option 2: although we may have less issues at the outset, we are
inevitably going to end up with the same issue that 2.6.33 is no longer
interesting and 2.6.34 is where development is going on; we end up at
(1) before long. This is also high risk as we expose all users to this
new code whether they would have a reasonable experience currently.

Option 3: here we have the work of trying to maintain the v2.6.32
versions of the drivers, but can optionally defer backporting invasive
changes by pushing the affected users to the backport. We do however
end up needing the X userspace to handle the DRM skew between the main
kernel and the backport.

Certainly for me option 3 seems the most appropriate here. We work the
kernel in our normal process, we maintain no major skew in that kernel
providing a low-risk base. The backports provides the safety valve for
the more invasive fixes and hardware enablement. We backport what is
sensible and safe, and where it is simply not practicle it goes into the
LBM module.

This however does place some effort on the X-team, and we would like to
start discussion on whether this seems sensible and maintainable from
the X side. For this to work, we would likely need to have X-server
support for both the v2.6.32 drm stack and the v2.6.33 drm (and possibly
later) stack. I have heard that it _may_ be possible to serve both of
these kernel stacks from the same userspace? Does the X-team think that
the current userspace bits are likely to be able to handle this level of
skew? Or if it is not do we think its practicle to try and handle it
this way? As I understand things we will have some v2.6.33 support
required for the current Nouveau plans so we may have to do this work
anyhow?

Anyhow I put this out there to start discussion.

Comments? Ideas? Feedback?

-apw


----- End forwarded message -----

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 01:31 AM
Bryce Harrington
 
Default Status of kernel X drivers

On Wed, Feb 17, 2010 at 05:50:33PM -0800, Bryce Harrington wrote:
> There seem to be a number of options here:
>
> Option 1 -- stick with v2.6.32: taking stable updates, backporting fixes
> and hardware enablement on a individually. Using blacklisting where
> appropriate to alieviate symptoms,
>
> Option 2 -- backport v2.6.33 drm: pulling back the v2.6.33 wholesale
> as that is where the developers are working, and
>
> Option 3 -- produce an LBM backport for drm: pulling back updates for
> drm wholesale for opt-in use; effectivly in combination with #1.
>
> Each of these have their own issues, and here I am trying to summarise
> the collective wisdom on these.
>
> Option 1: here we have the advantage that there is work ongoing in the
> -stable team pulling back and validating fixes for this release, this is
> expected to continue for the long term as v2.6.32 has been announced as
> long term support. This most closely fits the LTS model but is likely
> to have issues for cards at release which will need testing and
> managing.

This stays the most true to our original plans and thus is the least
disruptive to our current efforts. I think this could be a good option
*IF* we can get a LOT of kernel fixes and hardware enablement from
2.6.33 backported.

> Option 2: although we may have less issues at the outset, we are
> inevitably going to end up with the same issue that 2.6.33 is no longer
> interesting and 2.6.34 is where development is going on; we end up at
> (1) before long. This is also high risk as we expose all users to this
> new code whether they would have a reasonable experience currently.

I agree the risk level is high here. As well, there are at least a few
gotchas present in 2.6.33 that we'd need to get resolved, such as
needing the RLC firmware for r600-r700 (non-free license). And probably
more we don't yet know about.

> Option 3: here we have the work of trying to maintain the v2.6.32
> versions of the drivers, but can optionally defer backporting invasive
> changes by pushing the affected users to the backport. We do however
> end up needing the X userspace to handle the DRM skew between the main
> kernel and the backport.

This option is kind of a best-of-both-worlds options, but it's the most
complex of the three from a packaging standpoint. Testing the various
permutations could be challenging as well. It gives the user a lot of
power but also plenty of opportunity to shoot themselves in the foot.

A further benefit of this approach is that backporting upstream fixes
for 2.6.33 drm would be easier than if we pulled all of 2.6.33 drm in,
since it would just require updating lbm only, where SRU requirements
are simpler than for updates to the base kernel.

> Certainly for me option 3 seems the most appropriate here. We work the
> kernel in our normal process, we maintain no major skew in that kernel
> providing a low-risk base. The backports provides the safety valve for
> the more invasive fixes and hardware enablement. We backport what is
> sensible and safe, and where it is simply not practicle it goes into the
> LBM module.

I guess for this we'd need to configure things something like:

2.6.32 2.6.33
Intel -intel/KMS * -intel/KMS
ATI -ati/UMS ** -ati/KMS
Nvidia N/A *** -nouveau/KMS

For X components, I think as long as we have ones compatible with
2.6.33, potentially they'll be backwards compatible to 2.6.32.
But we'll need to verify that. If not, things could get messy.
Maybe some of the other Ubuntu-X guys can chip in some of their thoughts
on this.

* - For Intel/KMS, we probably need to blacklist all the 8xx cards.
Some of them might work, but users could then selectively use LBM
(2.6.33) in those cases.

** - The kernel would need to either shut off KMS for radeon in this
case, or blacklist the R100-R200 (and probably more) cards.

*** - In theory, we could allow users to uninstall LBM and return to
-nv. Honestly, though, most users will be going to -nvidia, so
it doesn't seem like this is worth the effort it'd take.

Bryce

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 11:57 AM
Timo Aaltonen
 
Default Status of kernel X drivers

On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:

> On Wed, 2010-02-17 at 18:31 -0800, Bryce Harrington wrote:
>>> Option 3: here we have the work of trying to maintain the v2.6.32
>>> versions of the drivers, but can optionally defer backporting invasive
>>> changes by pushing the affected users to the backport. We do however
>>> end up needing the X userspace to handle the DRM skew between the main
>>> kernel and the backport.
>>
>> This option is kind of a best-of-both-worlds options, but it's the most
>> complex of the three from a packaging standpoint. Testing the various
>> permutations could be challenging as well. It gives the user a lot of
>> power but also plenty of opportunity to shoot themselves in the foot.
>>
> As far as nouveau goes, this is pretty obviously the best solution; we
> won't be supporting nouveau except via the lbm packages, so there's no
> real packaging overhead. Also, if we wanted to ship a kernel component
> newer than that found in 2.6.33 we'd need to deal with the API bump that
> has been threatened for ages an has now been made. This would be
> difficult, but not impossible, to deal with. At this, post
> feature-freeze stage, I don't think it's worth the effort.

Why not? Aren't the fixes coming in .34 going to depend on the ABI bump,
meaning that backporting would be harder? (and the same for the ddx)

> I'd suggest that we stick with our current libdrm < 2.4.18, lbm-nouveau,
> and xserver-xorg-video-nouveau stack, and cherry pick & backport
> whatever fixes we want to grab. In which case, as long as there's a
> 2.6.33 drm in lbm, the nouveau stack is happy.

2.4.18 has other fixes in it, so better to just revert the offending
commit with a patch, and then decide if the ABI bump is worth it. Less
work than pulling a number of patches on top of 2.4.17.

--
Timo Aaltonen
Systems Specialist
IT Services, Aalto University School of Science and Technology

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 02:34 PM
Chase Douglas
 
Default Status of kernel X drivers

Timo Aaltonen wrote:
> On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:
>> As far as nouveau goes, this is pretty obviously the best solution; we
>> won't be supporting nouveau except via the lbm packages, so there's no
>> real packaging overhead. Also, if we wanted to ship a kernel component
>> newer than that found in 2.6.33 we'd need to deal with the API bump that
>> has been threatened for ages an has now been made. This would be
>> difficult, but not impossible, to deal with. At this, post
>> feature-freeze stage, I don't think it's worth the effort.

If nouveau is provided through lbm, and the (what I presume)
linux-backports-modules-nouveau package is installed by default, then should we
be considering how this will affect the SRU process for lbm as well? The current
SRU process for lbm is much looser than for the linux-image package. I assume
this is because lbm isn't installed by default and isn't fully supported in the
same manner. If we are going to be supporting nouveau to the same degree as we
do drivers in linux-image, perhaps we should think about splitting the nouveau
drivers out as a separate package. This would ensure that the support levels of
the lbm drivers are uniform instead of the mix that would entail if we put
nouveau in lbm.

A second proposal I'd like to make would be integrating some of these drivers
into jockey. Right now jockey proposes proprietary, marginally supported drivers
for ubuntu. This is similar to lbm in that the drivers provided are not
supported to the same level as the default modules provided by linux-image.
There are many cases, however, where the lbm drivers may solve issues for ubuntu
users. Unfortunately, lbm is not really advertised anywhere. I believe it would
be useful for users to have the option through jockey to install backport
modules, with all the disclaimers of level of support. This helps us not only by
providing a possibly better experience for end users when lbm fixes their
issues, but also through testing. We would be more likely to see bug reports
like, "My hardware doesn't work in lucid until I install lbm". We can find and
vet individual fixes more easily and integrate them into the linux-image package.

This would be very useful for cases where the intel drivers in linux-image can't
be fixed due to non-trivial backporting of patches, but the updated drivers
could still be provided through lbm. Jockey could look for graphics chipsets
that we know function better through lbm and then suggest them to the user just
like it's done today for proprietary drivers.

Thanks,
Chase

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 02:38 PM
Chase Douglas
 
Default Status of kernel X drivers

Timo Aaltonen wrote:
> On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:
>> As far as nouveau goes, this is pretty obviously the best solution; we
>> won't be supporting nouveau except via the lbm packages, so there's no
>> real packaging overhead. Also, if we wanted to ship a kernel component
>> newer than that found in 2.6.33 we'd need to deal with the API bump that
>> has been threatened for ages an has now been made. This would be
>> difficult, but not impossible, to deal with. At this, post
>> feature-freeze stage, I don't think it's worth the effort.

If nouveau is provided through lbm, and the (what I presume)
linux-backports-modules-nouveau package is installed by default, then should we
be considering how this will affect the SRU process for lbm as well? The current
SRU process for lbm is much looser than for the linux-image package. I assume
this is because lbm isn't installed by default and isn't fully supported in the
same manner. If we are going to be supporting nouveau to the same degree as we
do drivers in linux-image, perhaps we should think about splitting the nouveau
drivers out as a separate package. This would ensure that the support levels of
the lbm drivers are uniform instead of the mix that would entail if we put
nouveau in lbm.

A second proposal I'd like to make would be integrating some of these drivers
into jockey. Right now jockey proposes proprietary, marginally supported drivers
for ubuntu. This is similar to lbm in that the drivers provided are not
supported to the same level as the default modules provided by linux-image.
There are many cases, however, where the lbm drivers may solve issues for ubuntu
users. Unfortunately, lbm is not really advertised anywhere. I believe it would
be useful for users to have the option through jockey to install backport
modules, with all the disclaimers of level of support. This helps us not only by
providing a possibly better experience for end users when lbm fixes their
issues, but also through testing. We would be more likely to see bug reports
like, "My hardware doesn't work in lucid until I install lbm". We can find and
vet individual fixes more easily and integrate them into the linux-image package.

This would be very useful for cases where the intel drivers in linux-image can't
be fixed due to non-trivial backporting of patches, but the updated drivers
could still be provided through lbm. Jockey could look for graphics chipsets
that we know function better through lbm and then suggest them to the user just
like it's done today for proprietary drivers.

Thanks,
Chase

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 05:29 PM
Bryce Harrington
 
Default Status of kernel X drivers

On Thu, Feb 18, 2010 at 02:57:18PM +0200, Timo Aaltonen wrote:
> On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:
> > I'd suggest that we stick with our current libdrm < 2.4.18, lbm-nouveau,
> > and xserver-xorg-video-nouveau stack, and cherry pick & backport
> > whatever fixes we want to grab. In which case, as long as there's a
> > 2.6.33 drm in lbm, the nouveau stack is happy.
>
> 2.4.18 has other fixes in it, so better to just revert the offending
> commit with a patch, and then decide if the ABI bump is worth it. Less
> work than pulling a number of patches on top of 2.4.17.

I'd agree. Plus it'll be easier to explain "we're carrying 2.4.18 minus
patch foo".

Which is the commit(s) that needs reverted?

Bryce

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 05:34 PM
Bryce Harrington
 
Default Status of kernel X drivers

On Thu, Feb 18, 2010 at 10:38:07AM -0500, Chase Douglas wrote:
> A second proposal I'd like to make would be integrating some of these drivers
> into jockey. Right now jockey proposes proprietary, marginally supported drivers
> for ubuntu. This is similar to lbm in that the drivers provided are not
> supported to the same level as the default modules provided by linux-image.
> There are many cases, however, where the lbm drivers may solve issues for ubuntu
> users. Unfortunately, lbm is not really advertised anywhere. I believe it would
> be useful for users to have the option through jockey to install backport
> modules, with all the disclaimers of level of support. This helps us not only by
> providing a possibly better experience for end users when lbm fixes their
> issues, but also through testing. We would be more likely to see bug reports
> like, "My hardware doesn't work in lucid until I install lbm". We can find and
> vet individual fixes more easily and integrate them into the linux-image package.
>
> This would be very useful for cases where the intel drivers in linux-image can't
> be fixed due to non-trivial backporting of patches, but the updated drivers
> could still be provided through lbm. Jockey could look for graphics chipsets
> that we know function better through lbm and then suggest them to the user just
> like it's done today for proprietary drivers.

That's not a bad idea. I was wondering myself how we'd expose the
availability of new lbm bits to end users, and this approach seems quite
sensible. Pitti, what are your thoughts on this proposal?

Bryce

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 08:41 PM
Steve Conklin
 
Default Status of kernel X drivers

On 02/17/2010 07:50 PM, Bryce Harrington wrote:
> [Forwarding to ubuntu-x@ apw's summary of some discussions we've been
> having.]
>
> We have been chatting on and off in various forums about the state of
> the X drivers in the kernel, and it seemed time to get that discussion
> out onto the lists.
>
> The main question is really: "Are the drivers in v2.6.32 going to be
> supportable for the LTS?". This has been triggered by a strong upstream
> response of "That sounds like something we already fixed in 2.6.33, use
> that instead." to bugs we find in v2.6.32, this has been across all the
> graphics drivers.
>
> There seem to be a number of options here:
>
> Option 1 -- stick with v2.6.32: taking stable updates, backporting fixes
> and hardware enablement on a individually. Using blacklisting where
> appropriate to alieviate symptoms,
>
> Option 2 -- backport v2.6.33 drm: pulling back the v2.6.33 wholesale
> as that is where the developers are working, and
>
> Option 3 -- produce an LBM backport for drm: pulling back updates for
> drm wholesale for opt-in use; effectivly in combination with #1.
>
> Each of these have their own issues, and here I am trying to summarise
> the collective wisdom on these.
>
> Option 1: here we have the advantage that there is work ongoing in the
> -stable team pulling back and validating fixes for this release, this is
> expected to continue for the long term as v2.6.32 has been announced as
> long term support. This most closely fits the LTS model but is likely
> to have issues for cards at release which will need testing and
> managing.
>
> Option 2: although we may have less issues at the outset, we are
> inevitably going to end up with the same issue that 2.6.33 is no longer
> interesting and 2.6.34 is where development is going on; we end up at
> (1) before long. This is also high risk as we expose all users to this
> new code whether they would have a reasonable experience currently.
>
> Option 3: here we have the work of trying to maintain the v2.6.32
> versions of the drivers, but can optionally defer backporting invasive
> changes by pushing the affected users to the backport. We do however
> end up needing the X userspace to handle the DRM skew between the main
> kernel and the backport.
>
> Certainly for me option 3 seems the most appropriate here. We work the
> kernel in our normal process, we maintain no major skew in that kernel
> providing a low-risk base. The backports provides the safety valve for
> the more invasive fixes and hardware enablement. We backport what is
> sensible and safe, and where it is simply not practicle it goes into the
> LBM module.
>
> This however does place some effort on the X-team, and we would like to
> start discussion on whether this seems sensible and maintainable from
> the X side. For this to work, we would likely need to have X-server
> support for both the v2.6.32 drm stack and the v2.6.33 drm (and possibly
> later) stack. I have heard that it _may_ be possible to serve both of
> these kernel stacks from the same userspace? Does the X-team think that
> the current userspace bits are likely to be able to handle this level of
> skew? Or if it is not do we think its practicle to try and handle it
> this way? As I understand things we will have some v2.6.33 support
> required for the current Nouveau plans so we may have to do this work
> anyhow?
>
> Anyhow I put this out there to start discussion.
>
> Comments? Ideas? Feedback?
>
> -apw
>
>
> ----- End forwarded message -----
>

There was an interesting discussion on #dri-devel about this, with Dave Airlie
and others participating. Dave said that upstream development for .33 has been
focused on stability, and this is supported by looking at the patches I have
seen coming along in both radeon and intel drivers.

What was put forward as a possible approach was to do the following:

Backport the entire drm stack from .33 to Lucid. This gains us all the features
we want and brings us very close to where upstream is working. Future
backporting of fixes will be much easier, and being as far forward as we can be
will serve us best in the long time scale of the LTS release. It also gives us
all the major changes from the intel driver that are making backports of
individual features so difficult.

After release and if needed, create a lbm package to deliver .34 or .35 or
whatever we might need from future releases. If/when the upstream driver
developers stop concentrating on .33, we can maintain our main kernel with only
critical updates and backport the latest drivers for our lbm. Also, Dave Airlie
pointed out that as we move through post-Lucid releases, we will include .34+ in
these and get a sanity check of driver stability, etc before we make a decision
whether to pull them back into the Lucid lbm.

Having the lbm would also provide a good testing mechanism for xorg-edgers and
other people interested in testing the latest drivers.

With support from the X side, I think that this is a good solution.

Steve



--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 02-18-2010, 09:30 PM
Christopher James Halse Rogers
 
Default Status of kernel X drivers

On Thu, 2010-02-18 at 10:29 -0800, Bryce Harrington wrote:
> On Thu, Feb 18, 2010 at 02:57:18PM +0200, Timo Aaltonen wrote:
> > On Thu, 18 Feb 2010, Christopher James Halse Rogers wrote:
> > > I'd suggest that we stick with our current libdrm < 2.4.18, lbm-nouveau,
> > > and xserver-xorg-video-nouveau stack, and cherry pick & backport
> > > whatever fixes we want to grab. In which case, as long as there's a
> > > 2.6.33 drm in lbm, the nouveau stack is happy.
> >
> > 2.4.18 has other fixes in it, so better to just revert the offending
> > commit with a patch, and then decide if the ABI bump is worth it. Less
> > work than pulling a number of patches on top of 2.4.17.
>
> I'd agree. Plus it'll be easier to explain "we're carrying 2.4.18 minus
> patch foo".
>
> Which is the commit(s) that needs reverted?

libdrm would need b496c63143e9a4ca02011582329bce2df99d9b7c and I think
also 88e8a8bbaf026aa10225880001ab7ca1c392168a reverted.

If we're comfortable with pulling from the nouveau kernel tree[1] for
linux-backports-modules-nouveau, then going over the API bump would
indeed make cherry-picking and backporting fixes easier. The API bump
hasn't made it out of that tree yet, as far as I'm aware.

If we're additionally going to have lbm packages for intel and radeon
built from 2.6.34, I think it makes sense to pull from the nouveau tree
now, and later switch to the .34 tree when we pull the rest of the drm
drivers for lbm.

[1] http://cgit.freedesktop.org/nouveau/linux-2.6/

--
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 03:34 AM.

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