On Thu, 1 Aug 2002, Alex Deucher wrote: >Date: Thu, 1 Aug 2002 07:36:11 -0700 (PDT) >From: Alex Deucher <agd5f@yahoo.com> >To: xfree86-list@redhat.com >Content-Type: text/plain; charset=us-ascii >List-Id: Red Hat XFree86 list <xfree86-list.redhat.com> >Subject: Re: Radeon and Rage 128 VT switch bug finally squashed > >have you forwarded your fix to Xfree or DRI for inclusion/testing? It is not "my fix". It was C.P. Botha's fix (for Radeon) as indicated in the message you quoted. I made a patch to the r128 driver to do the same. Make no mistake: *ALL* Red Hat XFree86 patches are *ALWAYS* sent upstream to XFree86.org and/or the DRI project. If you see a patch in Red Hat Linux, and do not see it in XFree86.org sources or CVS tree's, then XFree86.org generally has not applied it to CVS for whatever their reasons. Sending patches to XFree86.org often results in them sitting there in a patch queue for 8-12 months. They are very busy people and do not have time to go over every patch as it is received as they come in, and commit them to CVS. However, regardless of the reasoning, it does not stimulate one to rush to submit patches immediately either. Normally, I submit a group of patches all at once to XFree86.org. I don't see the difference between submitting 1 patch at a time that will sit there for 6 months untouched, and waiting 6 months and submitting 85 patches at once. Patches which are of much greater importance, are usually sent immediately. The DRI project is different in this regard though, and since their focus is much narrower, changes sent to DRI folk, tend to get incorporated much quicker, discussed on mailing lists, etc. Whenever possible, I like to send patches to DRI developers instead, as they are likely to get included in CVS earlier that way, and then get picked up by XFree86.org during DRI merge. This also relieves XFree86 developers from the extra workload. Also, fortunately, I now have DRI CVS write priveledge, so I can commit changes like this myself to DRI-CVS. Hope this clarifies everything. Take care, TTYL >--- "Mike A. Harris" <mharris@redhat.com> wrote: >> On Tue, 30 Jul 2002, Alex Deucher wrote: >> >> >Date: Tue, 30 Jul 2002 10:27:39 -0700 (PDT) >> >From: Alex Deucher <agd5f@yahoo.com> >> >To: xfree86-list@redhat.com >> >Content-Type: text/plain; charset=us-ascii >> >List-Id: Red Hat XFree86 list <xfree86-list.redhat.com> >> >Subject: Re: Radeon and Rage 128 VT switch bug finally squashed >> > >> >there were some patches floating around on the the xpert or >> dri-devel >> >ML's last week that attempted to fix this. I believe the problem >> was >> >related to busmastering being unset during a VT switch. >> >> That patch from C.P.Botha is included in the RPM package below. >> I also wrote a patch for Rage 128 to fix the same issue there. >> Both are included in rawhide. >> >> >Alex >> > >> >--- Thomas Dodd <ted@cypress.com> wrote: >> >> >> >> >> >> Mike A. Harris wrote: >> >> >> >> >For new XFree86 packages for Limbo: >> >> > >> >> >ftp://people.redhat.com/mharris/testing/bleeding-edge >> >> > >> >> >> >> I grabbed the SRPM, and built on a Valhalla system. >> >> I flipped the switch to build drm, which failed for >> >> the i810 and i830 drivers. The patch to us udelay() instead >> >> of a for loop doesn't include <linux/delay.h> which >> >> defines udelay(). The other drivers which >> >> use udelay() do include that header. >> >> Like gamma_dma.c, mga_dma.c, r128_cce.c, and radeon_cp.c. >> >> >> >> I haven't tested the build yet. >> >> I'm also working on installing limbo2 (7.3.93) an a r128 box >> >> to test it there. >> >> >> >> Any known tricks to exercize the VT switch problem on >> >> a rage 128? >> >> >> >> -Thomas -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
