UBUNTU: [SAUCE] Update Poulsbo Video driver to build 5.0.0.0040

[Jim Lieb]

On Wednesday 15 April 2009 09:03:59 Tim Gardner wrote:
> Jim Lieb wrote:
> > On Wednesday 15 April 2009 07:14:09 Tim Gardner wrote:
> >> Jim Lieb wrote:
> >>> This patch is required for LPIA image build.  Steve Magoun has fetched
> >>> and is using the packages built from this patch for testing.
> >>>
> >>>     OriginalAuthor: Jason Chen <jason.chen at intel.com>
> >>>     Bug: #lp357760
> >>>    Update drm Poulsbo code to current Intel release with slight mods to
> >>> fit LUM build environment.
> >>>
> >>> The formatted patch is attached.  It can also be found at:
> >>>
> >>> git://kernel.ubuntu.com/lieb/ubuntu-hardy-lum.git lp357760
> >>>
> >>> Note that this patch is paired with a patch applied to the X server.
> >>> The patch was supplied/referenced in the bug report.
> >>
> >> I don't know what you're hoping for with this patch, but I can see no
> >> functional code change. There's a lot of DVD_FIX crap ripped out or
> >> refactored under '#ifdef  PSB_DETEAR', but the runtime behavior should
> >> be identical. Do you get any kind of changelog or notes from these guys
> >> as to why they are chucking this over the wall at you?
> >
> > There are notes in the bug and there were some on the referenced
> > intel tar ball.  This goes with an X driver update as well although I
> > haven't seen that code.  Here are the 3 lines from the debian changelog:
> >   * update the version for 5.0.0.0040
> >   * Improve the de-tearing performance
> >   * Refine the de-tearing code
> >
> > I can add them to the commit but they don't say much either.  The detear
> > code was added/enabled in 0038 which is about 3-4 commits earlier than
> > this one.  It is a dependency of the X server code upgrade.
> >
> > There is an issue here with how intel is releasing this stuff.  I noticed
> > this with the audio.  They seem to put out a debian package, quilt/dpatch
> > files et al and only later does something (somewhat different in the
> > audio case) go up to mainline.  I would rather have a git tree to
> > cherrypick from and thereby be able to record provenance and track with
> > the evolution of the code but this is what they throw over the wall.  OEM
> > has not had a whole lot of choices given schedules, both ours and
> > intel's.
>
> Perhaps Jason could respond:
>
> 1) Why are we getting monolithic patches? Its _very_ difficult to catch
> important details, especially when obscured by large changes in code
> structure.
>
> 2) I'm concerned about code provenance. Who actually did the work?
> Tungsten Graphics is listed as one of the original developers. Are they
> still contributing?
>
> 3) If it is difficult for you to host a git repository, I can certainly
> make one available for your use on kernel.ubuntu.com, unless you already
> have an account (there is already a jayc from Intel).
>
Agreed here.  Is this a question the OEM team passes on or should the
kernel group?  Given that these releases include the X server, I suggest
OEM suggests they change their ways and we help with git advice.  I'm
sure the RPM based OEMs have the same level of teeth grinding...

> > This is isolated off in the lpia branch so as not to iinterfere with main
> > hardy.  It is what it is.  If we find further issues with this, it makes
> > sense to keep this patch as-is and apply ours on top.
>
> While this patch may not interfere with the main distro releases, it
> _does_ affect a number of OEM platforms. I'm sure existing owners would
> be quite annoyed if they are regressed. Furthermore, this repository is
> going to exist for 4 more years. I'd just as soon not look back in a few
> months and wonder wtf was I thinking?
Agreed here too but there is not much latitude at this micro level.  A
5 year SLA and reproducibility requirement here is more than a bit
scary.  At least the LUM more or less dies with hardy but... In the end,
what is needed wrt this patch to include it into the topic branch?  What
other doc/reference should be added?  The code is a pass thru.

Jim
>
> rtg

-- 
Jim Lieb
Ubuntu Kernel Team
Canonical Ltd.