xf86-video-armsoc, Mali and exynos4

[Siarhei Siamashka]

On Tue, 12 Nov 2013 16:08:27 -0600
Daniel Drake <drake at endlessm.com> wrote:

> On Tue, Nov 12, 2013 at 3:49 PM, Luc Verhaegen <libv at skynet.be> wrote:
> > Fwiw, I am happily using a derivative of the standard fbdev driver on my
> > sunxi and exynos based devices. Namely fbturbo which is being done by
> > Siarhei Siamashka. For sunxi, it includes some knowledge about the
> > strangely implemented display engine, for exynos, it currently speeds up
> > some operations using neon assembler.
> 
> Yes, it does work reasonably well. Unfortunately this does not support
> xrandr resolution switching though

I was considering to get xrandr working at least on sunxi hardware.
So that dual monitor support and screen resolution switching at
runtime works in X11 desktop in a standard way transparently for the
applications and for the user. But then decided that it is not worth
the efforts. And very few people actually asked about this feature.

> which is now made available "for free" by the underlying exynos_drm
> display driver.

Does xf86-video-modesetting work properly with the exynos_drm kernel
driver on your hardware? It is useful to first check whether the
kernel is really functional.

A year ago just trying to load the modesetting DDX only oopsed the
kernel on my ARM Chromebook. But it is possible that things have
improved since then.

> Maybe we could add KMS support to fbturbo

Right now fbturbo is built on top of the xf86-video-fbdev chassis.
Just because it simply works everywhere and provides the best
compatibility with various hardware. Trying to hack the KMS support
into it may be a little bit invasive and the perfect compatibility
with the ump based mali400 binary blobs can't be guaranteed. The fully
open source driver for mali400 is going to provide a lot more freedom
in shaping a usable graphics stack.

The xf86-video-modesetting would be likely a preferred option instead
of xf86-video-fbdev if it worked everywhere too (at least on the
Raspberry Pi, Allwinner, Rockchip, Exynos4 and Exynos5 based hardware).

Now an interesting question is whether it makes sense to suspend all
the other activity and work on a better kms support in the kernel for
all this hardware simultaneously? Or first try to wait for decent
results on at least one platform (freedreno? armada?), learn from
this experience and then do the same for the other ARM platforms?

My primary motivation for fbturbo/sunxifb was ensuring a usable X11
desktop on the low end ARM hardware right now by fixing/workarounding
some obvious performance issues. It's a stop gap solution, which surely
needs to be replaced in the long run. But any potential replacement
must be confirmed to be better (not just assumed to be better).

> I was just interested in exploring things from the armsoc side
> as the original announcement talks about the combination of X/Mali
> integrated with exynos, DRM and KMS.
> http://lists.x.org/archives/xorg-devel/2012-May/031250.html
> Maybe that level of integration has not yet been reached in public
> code though :(

A lot may happen along the way, no matter how good or bad the original
plan was. I guess that Tom would be the best person to explain the
current status of this work.

-- 
Best regards,
Siarhei Siamashka