X for i810 video is still not working with xorg-x11-6.7.99.902-6

[Jim Cornette]

Since X is down for those with the 810 or 815 version of video cards, I 
have been copying the driver from the earlier X version that is on the 
FC3T1 CD to the below.

/usr/X11R6/lib/modules/drivers/i815_drv.o

When X is installed and is does not come up, I then replace the

/usr/X11R6/lib/modules/drivers/i810_drv.o

file with the working driver, in order to get my X up and running.

Anyway, on the newer installations, the older i810_dvr.o driver is 
replaced with the latest version. I therefore test out the newest driver 
and find that it failed.

This is interesting to me, except the below bug is said to be checked 
into CVS.

https://freedesktop.org/bugzilla/show_bug.cgi?id=1084 (and 1086)

How soon will this fix take to get incorporated into the next release of X?

Jim

PS: The connection problem that was reported earlier is now gone. After 
I downloaded the rpms for the days between 8/22 and today, on the FC2 
system. I chrooted in a mingetty terminal this test installation, 
mounted the directory which contained the downloaded rpms. I then rpm 
-Uvh *.rpm all of the packages within the directory that contained the 
downloaded rpms. 85 rpms upgraded and then after exiting the chrooted 
FC3T1 environment running in tty1 and closing down the FC2 applications 
(tty2, tty3 and X environment), I rebooted into the FC3T1 system and 
tested the NIC and X. X did not work, net did.


-- 
What a strange game.  The only winning move is not to play.
		-- WOP, "War Games"

[Mike Klinke]

On Wednesday 25 August 2004 21:57, Jim Cornette wrote:
>  Since X is down for those with the 810 or 815 version of video
>  cards, I have been copying the driver from the earlier X version
>  that is on the FC3T1 CD to the below.
>
>  /usr/X11R6/lib/modules/drivers/i815_drv.o
>
>  When X is installed and is does not come up, I then replace the
>
>  /usr/X11R6/lib/modules/drivers/i810_drv.o
>
>  file with the working driver, in order to get my X up and
>  running.
>
>  Anyway, on the newer installations, the older i810_dvr.o driver
>  is replaced with the latest version. I therefore test out the
>  newest driver and find that it failed.
>
>  This is interesting to me, except the below bug is said to be
>  checked into CVS.
>
>  https://freedesktop.org/bugzilla/show_bug.cgi?id=1084 (and 1086)
>
>  How soon will this fix take to get incorporated into the next
>  release of X?
>
>  Jim 
Jim, I can confirm that this is still broken with the xorg*902-6 
rpm's on my system too. I'd been waiting for the changed binaries 
but it looks like the patch may not have been added yet to the 
Fedora distribution.

Regards, Mike Klinke

[Mike A. Harris]

Mike Klinke wrote:
>  On Wednesday 25 August 2004 21:57, Jim Cornette wrote:
>  
> >Since X is down for those with the 810 or 815 version of video
> >cards, I have been copying the driver from the earlier X version
> >that is on the FC3T1 CD to the below.
> >
> >/usr/X11R6/lib/modules/drivers/i815_drv.o
> >
> >When X is installed and is does not come up, I then replace the
> >
> >/usr/X11R6/lib/modules/drivers/i810_drv.o
> >
> >file with the working driver, in order to get my X up and
> >running.
> >
> >Anyway, on the newer installations, the older i810_dvr.o driver
> >is replaced with the latest version. I therefore test out the
> >newest driver and find that it failed.
> >
> >This is interesting to me, except the below bug is said to be
> >checked into CVS.
> >
> >https://freedesktop.org/bugzilla/show_bug.cgi?id=1084 (and 1086)
> >
> >How soon will this fix take to get incorporated into the next
> >release of X?
> >
> >Jim
>  
>  
>  Jim, I can confirm that this is still broken with the xorg*902-6 
>  rpm's on my system too. I'd been waiting for the changed binaries 
>  but it looks like the patch may not have been added yet to the 
>  Fedora distribution. 
Correct, I've been intentionally avoiding applying patches that will 
then be removed a day or so later when we update to the latest CVS tag.

This way it gets fixed once in the place that matters (upstream) and we 
can just update to that on a relative schedule (relative to the RC 
releases).  The only patches I'm applying currently, are things that 
cause build failures, or are really serious and need fixing right away 
or the tree can't be composed.  This minimizes maintenance overhead, and 
allows more bugs to get fixed upstream, and more X.Org CVS matrix 
testing, and modularization feature work to be done.

The best thing for people testing the new X.Org out to do, is to report 
all non-rpm-packaging related bugs to X.Org bugzilla, and then follow up 
with X.Org developers in X.Org bugzilla (including myself).  Once 
something is fixed in CVS, it's safe to assume it will be in rawhide 
within 1-7 days roughly.

HTH

[Mike A. Harris]

Jim Cornette wrote:
>  Since X is down for those with the 810 or 815 version of video cards,
> I 
>  have been copying the driver from the earlier X version that is on the 
>  FC3T1 CD to the below.
>  
>  /usr/X11R6/lib/modules/drivers/i815_drv.o
>  
>  When X is installed and is does not come up, I then replace the
>  
>  /usr/X11R6/lib/modules/drivers/i810_drv.o
>  
>  file with the working driver, in order to get my X up and running.
>  
>  Anyway, on the newer installations, the older i810_dvr.o driver is 
>  replaced with the latest version. I therefore test out the newest driver 
>  and find that it failed.
>  
>  This is interesting to me, except the below bug is said to be checked 
>  into CVS.
>  
>  https://freedesktop.org/bugzilla/show_bug.cgi?id=1084 (and 1086)
>  
>  How soon will this fix take to get incorporated into the next release of X? 
I am updating the xorg-x11 rpms to new source code base, every time CVS 
gets a new tag, which in this case means, every new release candidate. 
Any patch that goes into X.Org CVS, will make it into rawhide after 
X.Org CVS gets tagged, and our main tarball gets updated to the new 
release and built in rawhide.  Expect to see new rpms within 2 days of a 
new CVS tag barring problems or other priorities that arise.

HTH

[Jim Cornette]

Mike A. Harris wrote:
>  Jim Cornette wrote:
>  
> > Since X is down for those with the 810 or 815 version of video cards, 
> > I have been copying the driver from the earlier X version that is on 
> > the FC3T1 CD to the below.
> >
> > /usr/X11R6/lib/modules/drivers/i815_drv.o
> >
> > When X is installed and is does not come up, I then replace the
> >
> > /usr/X11R6/lib/modules/drivers/i810_drv.o
> >
> > file with the working driver, in order to get my X up and running.
> >
> > Anyway, on the newer installations, the older i810_dvr.o driver is 
> > replaced with the latest version. I therefore test out the newest 
> > driver and find that it failed.
> >
> > This is interesting to me, except the below bug is said to be checked 
> > into CVS.
> >
> > https://freedesktop.org/bugzilla/show_bug.cgi?id=1084 (and 1086)
> >
> > How soon will this fix take to get incorporated into the next release 
> > of X?
>  
>  
>  I am updating the xorg-x11 rpms to new source code base, every time CVS 
>  gets a new tag, which in this case means, every new release candidate. 
>  Any patch that goes into X.Org CVS, will make it into rawhide after 
>  X.Org CVS gets tagged, and our main tarball gets updated to the new 
>  release and built in rawhide.  Expect to see new rpms within 2 days of a 
>  new CVS tag barring problems or other priorities that arise.
>  
>  HTH
>  
>   
This sounds reasonable. Thanks for the approximate timeframe from CVS 
checkin to available in rawhide.

BTW - the --target i686 worked flawlessly in generating the rpms for the 
902-4 build. The seperation work for different archs must be heading 
down the right path.

Jim

[Mike A. Harris]

Jim Cornette wrote:
>  This sounds reasonable. Thanks for the approximate timeframe from CVS
>
>  checkin to available in rawhide.
>  
>  BTW - the --target i686 worked flawlessly in generating the rpms for the 
>  902-4 build. The seperation work for different archs must be heading 
>  down the right path. 
I was able to find a nice clean way to access the canonicalized
architecture name, by using %{_arch} in the spec file, and using
"ulimit -i" in the script I wrote.  This works fantastic on all
architectures tested so far, and can be patched for others we
don't build on if anyone tries the newer packages and has problems,
ie: sparc/alpha/etc.

So, for x86, the canonical name is "i386", even if you build for 
i686/athlon/etc., so it should still work ok.  ;o)

Thanks for testing.