Re: Migrating ports from XFree86 to Xorg (Was: Changing default X11_TYPE from native to modular for some platforms)

[Michael <macallan1888%gmail.com@localhost>]

Hello,

On Thu, 22 Sep 2011 11:35:25 +0200
Frank Wille <frank%phoenix.owl.de@localhost> wrote:

> On Wed, 21 Sep 2011 10:35:42 -0400
> Michael <macallan1888%gmail.com@localhost> wrote:
> 
> > Most drivers do not depend on wsdisplay, and those which do are
> > things like crime ( which can't be probed through some sort of bus so
> > it uses /dev/ttyE0 to talk to the kernel driver ) and wsfb
> > ( obviously )
> 
> Ok. So we could theoretically port an Xorg driver before wsdisplay
> exists? Nice.

Yes.

> > The mouse and keyboard drivers pretty much require
> > wscons though.
> 
> Which means wskbd and wsmouse is required?

Well, wskbd and wsmouse support are in place, if you want to use something else 
that would be more work.

> Those drivers already exist for amiga, but as I understand wskbd only
> works with a wsdisplay. When there is an ite driver running, then the
> keyboard events are fed to it instead (according to amiga/dev/kbd.c).
> 
> So the ite must be closed when starting an Xorg driver to make wskbd
> connect it...? Sounds complicated.

I just had a quick look at the grf / ite code - it shouldn't be all that 
complicated to support wsdisplay at grf - the drawing methods are slightly 
different but that can be handled by a few lines of translation code. s far as 
I can tell, whatever wsdisplay needs is already in place, just needs a little 
bit of work to match.
That would allow you to leave the drivers alone and only have new ones support 
wsdisplay directly.

> > If you have a mappable framebuffer then attaching a wsdisplay on top
> > of it is pretty much trivial.
> 
> Great! That's what I hoped.
> So I still think we should do the new wsdisplays first, as it would also
> solve the confusion mentioned above.

See above :)

> I'm only unsure about the screen modes. Currently we are loading a screen
> mode definitions file using grfconfig(8) into the grf driver, which
> contains the exact timings and dimensions for the modes.
> 
> Maybe we should just include some fixed VESA modes in wsdisplay instead?

Why change it at all? Wsdisplay doesn't know or care about video modes and 
there is no standard API for programming video modes anyway.

> > The only problem I see is with the
> > Amiga's built-in graphics hardware which doesn't give us packed
> > pixels as far as I know.
> 
> True. But IMHO this is not extremely important to support. I doubt that
> many people want to run X in flickering 640x400 interlaced at 30Hz.

And the drawing methods are already there, no need to use rasops at all so that 
point is moot.

> > > A typical NetBSD/amiga user will have a special Amiga graphics card
> > > (usually CirrusLogic or S3 based) in a Zorro3 slot.
> > 
> > Xorg has drivers for both, adding support for Z3 on top of PCI would
> > not be that hard. Or one could do what I did with the ag10e driver -
> > take the chip-specific part and stick it in a new driver that knows
> > about the new bus, maps stuff etc. so the rest of the driver can
> > work.
> 
> Sounds good. I only wonder why this hadn't been done in the past. The
> X drivers for these chips certainly existed before the Amiga drivers
> were written.

I don't know much about these cards, maybe there was a reason.

> > I suspect the Cirrus and S3 chips mentioned above will be VLB
> > or PCI variants with some Z3-specific glue logic.
> 
> Exactly.

If you can just map the registers and they look like what they'd look like on 
the PCI or VLB variant we shouldn't have any trouble. No clue if they need 
special handling, if there's endianness-twiddling hardware or whatever that 
would screw us over when trying to use the unmodified driver code.
Also, some chips use external DACs and/or clock chips which may or may not be 
different from what's commonly used on the PC variants.

have fun
Michael