[Openpvrsgx-devgroup] how to run gles2test1

[H. Nikolaus Schaller]

> Am 16.11.2019 um 18:32 schrieb Tony Lindgren <tony at atomide.com>:
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [191116 17:22]:
>> Hi Tony,
>> 
>>> Am 16.11.2019 um 17:37 schrieb Tony Lindgren <tony at atomide.com>:
>>> 
>>> * H. Nikolaus Schaller <hns at goldelico.com> [191116 08:21]:
>>>> Just a note for the archives:
>>>> 
>>>>> Am 16.11.2019 um 08:51 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>>> 
>>>>> I have looked into the testing-v5.4 tree and it is based on
>>>>> DDK 1.9.2253347 which we also have in the linux_openpvrsgx tree.
>>> 
>>> OK. I guess that's the same tree pyra was using with the
>>> tiler patches on top?
>> 
>> Tiler is independent. It works with or without.
>> I should dig out the omap5evm and connect a HDMI monitor...
> 
> OK. Just wondering how configuring tiler and changing the
> rotation fits into all this.

Well, that is indeed unknown...

The tiler things for the Pyra mainly rotate the framebuffer
so that a text console or /dev/fb0 is rotated properly.

X11 using DRM can rotate independently.

If you look at the new demo video, the orientation between
pyra and beaglebone black is 90° because the tiler is not
active with SGX...

> 
>> Anyways, I run all my tests with DDK1.14.3699939.
> 
> OK
> 
>> What I mean with the DDK 1.9.2253347 is that it is the "omap5"
>> subdirectory that was in our earlier versions. I have just
>> renamed it to letux/pvr-srvkm-1.9.2253347:
>> 
>> https://github.com/openpvrsgx-devgroup/linux_openpvrsgx/tree/letux/pvrsrvkm-1.9.2253347
>> 
>> It should be the same basis as the sgx tree you have based your testing-v5.4
>> tree on (except different file paths).
>> 
>> So it should be possible to port your testing-v5.4 to the
>> pvrsrvkm-1.9.2253347 tree and tweak the Makefiles a little
>> so that we can use the linux_openpvrsgx tree as well.
> 
> OK. Well the pvr-omap4 testing-v5.4 has nasty ioctl proxying
> dependencies to patching also omapdrm just to get it to
> compile. AFAIK these hacks can never be merged to mainline
> Linux, and will probably be a constant maintenance hassle.

Ok, I see.

> Probably best to keep them out, or at least wait until I
> have things working with the command translation so we
> have a better idea what should be done with them.

Yes, that looks like a good strategy.

Maybe we do not have to really activate linux_openpvrsgx the
DDK1.9 unless it would help to better understand/test the
transition.

Anyways, your testing-v5.4 is a good test-bench to compare against.

> I cross fingers that it works. We also may have to "translate"
>> the SGX version information since some user-space variants appear
>> to check which DDK version the kernel driver was built with.
>> 
>> At least I remember messages when trying the DDK1.10 user-space
>> with DDK1.14 kernel module.
> 
> Yeah I think we need to be able to emulate whatever version
> to the userspace blobs.

Looks like:

echo 1.14.3699939 >/sys/..../pvrsgx/version

BR,
Nikolaus