Getting Xglamo upstream

[Adam Jackson]

On Mon, 2008-10-13 at 20:07 +0200, Holger Freyther wrote:
> Morning,
> 
> for the Openmoko Freerunner we have a dedicated GPU (Glamo) and a dedicated 
> kdrive based X (Xglamo). I'm in the process of forward porting the changes to 
> the server 1.5 branch and would like to get the result included in the 
> upstream xserver repository. What steps to take to make this happen? Is there 
> any interest?

I think the general attitude towards kdrive is one of malign neglect.
We'd rather see more Xorg drivers and see its footprint reduced to the
point where it's acceptable for embedded people as well as normal
people.  That said, many of the fixes you've got look reasonable.

There's been a move towards more of a review culture on the list, and I
think that's a good thing.  So probably the best thing to do is go
through the steps for getting an fd.o account:

http://www.freedesktop.org/wiki/AccountRequests

and then ask the list for review, either with patchbombs or by linking
to topic branches as you've done.  Once you sense approval (or timeout)
then go ahead and merge them to master.

Initial review below, although bear in mind this is review relative to
master.  Given that kdrive is a pretty special case I'd suggest keeping
a parallel tree based on 1.5 until master gets to a point where you can
consume it directly (and, hopefully, you port the driver to the xfree86
ddx).

> OpenEmbedded patches (with varying degrees of correctness):
>       http://git.openmoko.org/?p=xglamo.git;a=shortlog;h=xorg/oe-patches

The first two mode patches are inoffensive in themselves, although the
idea of a huge static list of modes in a server designed for minimal
size is kind of contradictory.  Oh well.

The default mode patch is a little iffy.  I'm not that familiar with
kdrive's output setup, but I would think if you wanted to override the
default you should do it from the driver.

The APM patch is not okay.  That code should be harmless if you don't
have apm support in the kernel, but at any rate it should be controlled
by autoconf macro and not just disabled perforce.

The serial patch is fine, we should probably just take out access
to /dev/ttyS* entirely and tell people to use evdev.

The renderproto patch looks really suspicious.  What was the failure
case you were getting without that?  Typically we try to keep client and
server headers separate and don't include client headers from the
server.

The dixfonts patch is right out.  Outside of hw/, you should only ever
#include <dix-config.h>, because outside of hw/ the code is generic and
not bound to a specific DDX.  For this particular case you should be
able to get the same effect from --enable-builtin-fonts these days.

> Fixes and features:
> 	http://git.openmoko.org/?p=xglamo.git;a=shortlog;h=xorg/fixes-and-features
> 
> 	including handling > 127 medium raw keycodes and properl discarding them... 
> tslib compile fixes

tslib fixes look fine.

We suppress the cursor until the first XDefineCursor() call now.  I'm
not super-thrilled about adding a ppm loader, but I could probably be
talked into it.

Optional XKB isn't going to fly I don't think, Daniel's pushing pretty
hard to make it mandatory since it cleans up the input code
significantly to do so (which will make the XKB support code much
smaller, reducing the desire to compile it out in the first place).

KAA is gone in master.  You get to port to EXA!  Aren't you thrilled?  I
did that conversion once long ago for Xati, and it was pretty
mechanical.

Factoring out the keycode table looks fine to me.

I'm not entirely sure what the extended keycode thing is on about, but
it looks harmless enough.  Daniel?

> Addition of Glamo to the tree:
> 	http://git.openmoko.org/?p=xglamo.git;a=shortlog;h=xorg/glamo

Skipping these for now, xf86-video-omap is a longer discussion.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081014/3d8163c9/attachment.pgp>