Re: XFree86 4.1.0: call for help
Kostas Gewrgiou wrote:
>
> 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)
That's my point, either we don't need anything anywhere (we don't need to save
the VGA mode with fbcon) or we need nothing on some machines and everything on
others. Saving and restoring only part of the VGA context doesn't make sense
to me.
> > > 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
> need.
Which won't work without kernel assistance, will it? So we could as well just
let the existing syscall handle everything.
> 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.
Yup, but that's for 4.2 at the earliest...
--
Earthling Michel Dänzer (MrCooper) \ Debian GNU/Linux (powerpc) developer
CS student, Free Software enthusiast \ XFree86 and DRI project member
Reply to: