[Gta04-owner] xf86-video-omap

Dr. H. Nikolaus Schaller hns at goldelico.com
Fri Oct 21 14:14:52 CEST 2011


Hi Neil,

Am 21.10.2011 um 13:46 schrieb Neil Jerram:

> I discovered that "xrandr -o 3" doesn't work, because of the omapfb driver not supporting RANDR.
> 
> Then a bit of research discovered
> 
> http://lists.debian.org/debian-devel/2011/09/msg00095.html
> - Sebastian Reichel's intent to package the alternate "omap" driver
> 
> and
> 
> http://www.phoronix.com/scan.php?page=news_item&px=OTg3MA
> - a blog about TI releasing the code behind that omap driver.
> 
> What I'm not clear about, though, is whether these latest pieces of news mean that the omap driver will still require some binary blobs somewhere; or if the kernel and driver code will be fully free.  Can anyone clarify that?

I have not looked into details but I think all the drivers are completely
open source and free.

Debian lists the currently used driver sources as:

	http://packages.debian.org/source/sid/xf86-video-omapfb
	http://anonscm.debian.org/gitweb/?p=collab-maint/xf86-video-omapfb.git
	http://packages.debian.org/source/squeeze/xf86-video-omapfb

On the kernel level there was a 'DSS' driver which was replaced
by a new DSS2 driver. That one allows to control the OMAP
display hardware controllers so that they DMA from memory
through an overlay manager to either LCD and/or TV out.

I think the DSS2 is also capable for rotation (it would just
address the framebuffer memory differently) but some bits and
pieces may be missing in the 2.6.32 kernel.

On the X-Org server side there is the omapfb which simply
puts pixels into one of the framebuffers.

the xf86-video-omap3 package is optimized for the NEON
vector FPU (most likely used for alpha-blending calculations).

About the references you have found I think they are yet
another video driver. I am not sure if it will replace DSS2
but some hints are that it is about dynamic memory allocation
in the kernel and zero-effort rotation. It was already maintained
by some Texas Instrumens team as open source and is now
submitted for upstream.

Finally, the whole 2D video system is simple hardware
plus clever software. And no binary driver in between.
We even use some simple *address=value lines in U-Boot
to make the LCD show the initial boot splash which is
loaded from SD card to address 0x80000000.

A different thing is the 3D engine of the OMAP SoC. That
one needs a binary driver. Maybe, Rene reads this and
can share some knowledge.

-- Nikolaus


More information about the Gta04-owner mailing list