[pkg-fso-maint] libdrm-glamo and KMS-enabled xf86-video-glamo in pkg-fso

[Timo Jyrinki]

2010/3/13 Sebastian Reichel <elektranox at gmail.com>:
> I guess it's easier to add KMS support to the Debian kernel when we
> are using the mainline kernel, because adding support for it before
> that we just make the switch harder. So long users can use non
> packaged kernels if they want KMS support. Do you agree?

I don't immediately see how switching is made harder in either way,
but probably the default kernel should be non-KMS one for now, or
eventually whatever mainline kernel happens to include. But I think we
could offer for example KMS-enabled 2.6.32 (or later when available)
as a separate package so people could try out KMS by simply switching
the kernel package. Like I said, xf86-video-glamo automatically
detects if KMS is available or not, so the user does not need to do
anything else besides choosing a kernel to his/her liking.

Either way, 2.6.32 is not yet entirely ready for general consumption,
KMS or not. At least accelerometers are missing still.

> IMHO more interesting is the XVideo Status. I don't believe we will
> get much 3D power from the Glamo, but it should be possible to play
> 480x640 videos :P

I think there is no such thing as a so small power that something cool
couldn't be done with it :) I'm mostly thinking about if a one or two
Clutter objects could be operated semi smoothly, we could be in for
some rather nice UI stuff for eg. application launcher or for example
as a intone-like frontend to music playing. Just wishful thinking, but
I'd like to try 3D out as well.

The way to go with video playing is probably the MPEG4 HW acceleration
in Glamo, if someone figures out how to bring the old (but working)
MPlayer hack over to current stack somehow more sanely. Or maybe just
port the glamo patch to newer MPlayer and package it. I'm not sure if
any other hardware scaling is actually possible, than letting the chip
decode the video data as well.

-Timo