Process to merge Openchrome work

[Dave Airlie]

>
>        This last year the Openchrome support for the VIA chipsets has
> come along way from being in a state of decay. The plan is to release
> a Xorg driver June 1 that will have support for the KMS as well as UMS.
> The goal is to have this xorg driver out in the wild before the kernel
> side is ready so that the migration to the new kernel drivers will be
> as painless as possible. My hope is to merge the kernel tree for public
> use for Christmas.
>        This brings up the question I had with the other project leader.
> How does one go about merging the tree? What makes this more complex is
> that a old via drm kernel driver already exist. Do we just drop in the
> code into the staging area? Does it have to be piece meal? Does a rename
> of the driver need to happen? What would you recommend ?

So what we've done before to avoid regression is

a) add a new CONFIG_ option that is default n, so users don't get a regression,

b) enable the KMS bits and PCI binding depending on the new option.

Now the easiest way may be to make a new driver with a new name, make
it bind to PCI devices etc,
and just have CONFIG to turn it on/off. It depends on how much code
the new driver shares with the old etc.
So older distros can share the older code.

Then you'd have to generate decent reviewable patches of the codebase
and send them to dri-devel,
where others could review them. The main thing review looks out for is
that the userspace interfaces are
sane and secure.

I don't generally take git merges until people have built up a bit of
trust sending decent patches, and making sure reviews are done.

The other question is what to people lose if they switch to VIA KMS in
terms of acceleration, is the 2D/3D Xorg/Mesa driver work
at the same level as the old driver? does anyone care?

Dave.