Test results on Toshiba AC100/error messages

[emulti]

Testing xf86-video-opentegra on AC100 with mainline/stable kernel 5.1.1, Arch Linux ARM. Driver and assocated mesa etc. built on AC100 using AUR packages from aa13q. Kernel has CONFIG_ARM_TEGRA_STAGING enabled or the driver won't load. Some CFLAG adjustment (remove -fno-plt) was needed to allow xf86-video-opentegra load-time 'undefined symbol' errors. glxgears improves from 27 with modesetting driver to 66fps.

Some gui applications (ex: Midori) fail to draw screen correctly with:

grate_screen_get_param: unsupported parameter: 159
(repeats multiple times)
grate_screen_get_param: unsupported parameter: 159
WebKitWebProcess: grate_resource.c:200: grate_screen_resource_create: Assertion `format >= 0' failed.

[kusma]

OK, so the last bits sounds more like mesa issues than xf86-video-opentegra. The latest version of the mesa driver has moved a bit, it's now located here. I should probably push out our branch to point to the same commit as well.

Anyway, this sounds like rendering to an uimplemented format. I should really add some better logging here :)

[digetx]

Testing xf86-video-opentegra on AC100 with mainline/stable kernel 5.1.1, Arch Linux ARM. Driver and assocated mesa etc. built on AC100 using AUR packages from aa13q. Kernel has CONFIG_ARM_TEGRA_STAGING enabled or the driver won't load.

This is expected, you'll get a message in the Xorg's log telling to enable CONFIG_DRM_TEGRA_STAGING.

Some CFLAG adjustment (remove -fno-plt) was needed to allow xf86-video-opentegra load-time 'undefined symbol' errors.

From where that flag is coming from? It shouldn't be set implicitly by anything, Xorg modules rely on the lazy linkage.

Some gui applications (ex: Midori) fail to draw screen correctly with:

OpenGL implementation is incomplete and unusable by generic applications, export LIBGL_ALWAYS_SOFTWARE=1 globally. Opentegra driver provides drawing acceleration for X Render API, etc.

[digetx]

@kusma please back up the current master before the pushing because all of packaging scripts rely on autotools, I'll update the packaging later on.

Hmm, updating mesa will break the packaging scripts that I don't have access to (like the Arch's one). Although the things are expected to break (especially mesa) since we never stabilized anything.

[emulti]

The CFLAGS adjustment is to an Arch Linux default, set in /etc/makepkg.conf, used if the Arch PKGBUILD files are used for building with the Arch script makepkg aa13q is aware, through comments on https://aur.archlinux.org/packages/xf86-video-opentegra-git/ Browser not using OpenGL acceleration (ex: Epiphany) works fine, but of course not accelerated. We can no doubt adjust the PKGBUILDs after your updates

[digetx]

@emulti, so is everything resolved now?

BTW, you could get a bit more FPS in glxgears by running it with VSYNC disabled:

vblank_mode=0 glxgears

[emulti]

Yes, understood that OpenGL implementation is not complete. Will it be possible to do, by reverse engineering? I'm happy to test future builds on my ancient AC100.

[kusma]

@emulti: Yeah, the understanding of the hardware is reasonably complete. But implementing two proper compiler back-ends is rather time consuming, so we haven't gotten there yet.

[digetx]

Mesa is on TODO list. Any kind of help is welcome, including basic testing and general feedback.

Tegra2 may look like a bit too old now, but there wasn't anything radically better in regards to openness and tolerable hardware complexity (at least from Tegra SoC's perspective), older Tegra's are a good option if you don't have huge demands. I'm using it every day for pretty much everything and still there is a lot of potential.

Please don't hesitate to contact us if you'll have any problem or question, contributions are very welcome as well. I'm closing this issue since everything is resolved.