[haiku-development] Re: Makeshift patch for PPC

"François Revol" <revol@xxxxxxx> wrote:
> I recall seeing a Linux-ppc patch to implement vm86 emulation on ppc
> to
> be able to run the VESA BIOS on those, that seemed a bit clumsy but
> maybe the only way to really get some cards working.

Indeed. Although usually, the PPC firmware takes care of the
initialization, so Haiku doesn't have to care about this anymore (if it
is not interested in changing the screen resolution afterwards).

> Does app_server actually hardcode "vesa" ?
> As long as there is a device published it should try it before using
> vesa anyway, so if we make sure to publish an of-fb device it
> shouldn't
> be a problem.

It's hard-coded in the sense that it is ignored when there is another
device available. This special treatment, however, could be removed
once all graphics drivers follow the new driver architecture.

> The same problem with be there for m68k anyway.

Just that you usually will have built-in graphics that require a driver
anyway.

> What about instead of using a "fallback_" or other prefix or suffix,
> like "vesa_fallback", and filtering out strstr("_fallback") at the
> first pass when finding devices ?
>
> Another option is to have a "fallback" symlink pointing to "vesa" or
> "of" or whatever, but that requires the driver publishing it via
> devfs.

I think the VESA driver should still be able to work off of a
predefined framebuffer and resolution only.
Maybe we can rename it to something more appropriate (and leave the
VESA driver as is), but since it's the fallback driver anyway, I think
we can and should just keep it as is (by making the vm86 support
optional).

> Picking the first one won't work anymore when we want to support
> multiple card/screens anyway.

That's already taken care of in the app_server, it just doesn't do
anything with it yet.
Some day, when I have more time to play with the Intel driver again, I
will also explore multi screen scenarios by implementing a virtual
HWInterface subclass that combines several AccelerantHWInterfaces
(either by cloning the actions or enabling a large screen that spans
over more than one card).
That's also necessary to play with the accelerant interface in order to
properly extend it for multi head cards.

Bye,
   Axel.

Other related posts: