[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: XFree86 4.1.0: call for help

On Wed, 20 Jun 2001, Michel Dänzer wrote:

> Kostas Gewrgiou wrote:
> >
> > On Tue, 19 Jun 2001, Ani Joshi wrote:
> >
> > > On Tue, 19 Jun 2001, Michel [iso-8859-1] Dänzer wrote:
> > >
> > > > That would be nice, unfortunately it doesn't. For the record, here's the
> > > > patch against xf-4_1-branch I tested:
> > >
> > >
> > > Please try the attached patch.  This fixes the problem on PCI machines and
> > > could possibly fix yours too.
> > >
> > > It is against the stock 4.1.0 driver.
> It works BTW.

> > It will probably work for us, but it can't go in the XFree code
> > the problem is linux/ppc specific and has to be fixed in the
> > os specific part of the code. LynxOS/Pmax handle the
> > ioBase problem (only the first bridge is supported there) and
> > i assume that they need the vga font restore code.
> Why don't we need that and colormap anyway?

Since fbdev is handling the console there is no need to restore
vga fonts/colormap (i don't know if it is possible to run vgacon
under some of the ibm machines, if yes then it is needed there)

> > The #ifdef __powerpc__ isn't right (and we can't use os specific
> > code in the drivers) so the fix has to go in another layer,
> > crippling another os to fix our problems isn't the right solution.
> So, what can we do? We can't put arch or OS specific code to handle this in
> vgaHW either. Maybe it's really best to handle it in the kernel?

Everything that is os/arch specific more or less goes in xfree86/os-support
adding something like xf86isIOAvailable(device/screen/whatever) is what we

We still need to workout a way to handle multiple ioBases btw, there are
other paths in the code that will do io in the wrong base and we need
to handle this. Anyone with a second card in the pci bus will end up
getting the isa io access for the agp card in the wrong card and thats not
what we want.


Reply to: