[xorg] building xf86-video-intel against an older X server

Alan W. Irwin irwin at beluga.phys.uvic.ca
Mon Feb 25 09:43:42 PST 2008


On 2008-02-25 12:56+0100 Julien Cristau wrote:

> Hi all,
>
> I'd like to get xf86-video-intel included in an update to Debian stable
> (http://wiki.debian.org/EtchAndAHalf), which only has xserver 1.1.1.
> The intel driver tarballs ship with a copy of some xserver code in the
> src/modes and src/parser directories.  However that code comes from
> xserver master, and doesn't build against older headers.  Some examples:
> - MODE_BANDWIDTH in the ModeStatus enum is only available on master, but
>  used in modes/xf86Modes.c
> - the MonRec structure has a maxPixClock field in 1.4 and master, but
>  not in 1.3 and earlier;  it's used in modes/xf86EdidModes.c
> What's the best solution for this?  Copying the code from xorg-server
> 1.3 instead, thus making sure it builds, but possibly missing some bug
> fixes?  Or hacking the xserver code in master to keep building against
> headers from 1.1?
> Any advice appreciated :)

I don't think this is a good idea.  Here is why.

The Intel driver team has has not been able to verify my own recent bug
report for the Intel driver
(#http://bugs.freedesktop.org/show_bug.cgi?id=14430) which has been
confirmed by one other user) and some other bug reporters for the Intel
driver are also having the same difficulty.  In my own case I was using
Debian unstable versions of all kernel, drm, mesa, and X server components.
In some cases that is the latest release or near it, in other cases that is
actually a git version so you can say Debian unstable is pretty close to the
cutting edge here.  But from what the Intel driver team has said, their test
environment is even closer to the cutting edge, i.e., all git, all the time.
:-)

My working hypothesis for the verification difficulties is that the Intel
driver is written for bleeding edge support components, and if you don't
have those (and even Debian unstable does not qualify) then you are going to
run into problems that the Intel driver team will not be able to verify.

BTW, I emphasize this is not a criticism of the Intel driver team.  In the
current rapidly changing X world, they cannot test against all recent
variations of kernel, drm, mesa, and X server.  Furthermore, their actual
choice of going with bleeding edge components for testing their driver
should work out well a year or so from now when X and the rest will have
hopefully settled down a bit.  But the current situation does mean that the
latest Intel driver is not suitable (IMO) for older environments such as
Debian stable.  Thus, my guess from the experience I have had with the Intel
driver for Debian unstable is it would be a ton of work to adapt the Intel
driver and Debian stable to each other.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________



More information about the xorg mailing list