On Tue, 12 Nov 2013 16:08:27 -0600 Daniel Drake <[email protected]> wrote:
> On Tue, Nov 12, 2013 at 3:49 PM, Luc Verhaegen <[email protected]> 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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
