Qt with GLES on arm64 maintainer's decision - Was:: Upcoming Qt switch to OpenGL ES on arm64

[Re4son]

Hi,

On 26/11/18 11:54 pm, Riku Voipio wrote:
> On Mon, Nov 26, 2018 at 12:37:57PM +0100, Raphael Hertzog wrote:
>> were in the week-end). I was aware of the discussion but did not
>> had the time to chime in, yet I was the person who re-opened the bug
>> #881333 in the first place.
>  
>> I also invited someone else who is working on a concrete project involving
>> Kali Linux (Debian derivative) and off-the-shelf arm64 hardware available
>> now but he also did not have the time to contribute to the discussion.
>> Software can be fixed/improved to also work with OpenGL ES. However
>> hardware, once bought, cannot be fixed to support Desktop OpenGL
>> when it has been designed for OpenGL ES only.
> Reading from #881333 you mean Gemini PDA. It comes with Mediatek X27,
> featuring Mali-T880. The hardware is not OpenGL ES only .. the
> propiertary driver is. Mesa-based panfrost driver should support both
> OpenGL and OpenGL ES:
>
> https://gitlab.freedesktop.org/panfrost
>
> The open source driver is of course not ready... ...but neither is
> Debian ES 2.0. In the long run, making the driver ready is time better
> spent than time spent trying to make Debian more friendly to a class
> of propiertary drivers.

I fully agree again.
Looking at the lengthy progress so far and the limited resources
available, I suggest supporting the development by switching to GLES and
work on the drivers to support that first. Once that has been achieved
we can aim for full OpenGL support and then we can switch back to
desktop if there is actual user demand. I'm not suggesting to make
Debian more friendly to proprietary drivers. The exact opposite:
switching to GLES to fill the void will give us time to aim for one
milestone at a time. The vast majority of devices we are talking about
are embedded systems, let's aim to bring them the drivers and interfaces
that have been designed for embedded systems before we reach for the stars.
A lot of the discussion in this thread seems off topic and academic but
I’m confident that the above approach is what we need to move on.

> Riku
>
Many thanks