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

[Rohan Garg]

Hey
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
>
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.
>

AFAIU by building Qt with GLES we'd still be able to make use of mesa as it
provides both GL and GLES capabilities, while also allowing Qt to make use
of blobs if a user so chooses.

> > By choosing to build Qt with GLES on ARM64, we make Debian a more
> > attractive platform for vendors who'd like to target ARM64 boards.
>
> We should make it attractive for vendors to release their code under
> a free software (DFSG) license. That way anyone would be able to hack on it
> and add missing support for a different OpenGL variant, if needed.
>
> That said, as Lisandro announced, we will be happy to make any decision
> if there is either a consensus or a TC decision about it.
>

Ack.

Cheers
Rohan Garg

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

[Lisandro Damián Nicanor Pérez Meyer]

El martes, 27 de noviembre de 2018 17:19:32 -03 Dmitry Shachnev escribió:
> Hi Rohan!
> 
> On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> > [...]
> > 
> > I concur here. It was correctly pointed out in another reply that by using
> > OpenGL we're specifically catering to software that doesn't support
> > GLES while making performance worse for mature applications that
> > do implement both OpenGL and GLES. The reality of the situation is that
> > the market currently favors GLES over GL on ARM SBC's, delivered with
> > proprietary blobs. I think a more pragmatic view of this reality would be
> > to deliver the best FOSS user experience that's possible with the
> > proprietary drivers while the open source drivers are being improved. To
> > that extent, by switching to GLES we improve the overall situation since
> > OpenGL applications can fall back to software rendering via mesa on
> > platforms where mesa does not support the GPU.
> 
> Here I agree with Luke Kenneth Casson Leighton’s opinion [1].
> 
> I think we should aim to provide the best possible experience with the free
> software ecosystem. The experience with proprietary drivers should be the
> second priority, if priority at all.

I can't but agree here.

-- 
Una vez que hemos eliminado lo imposible, lo que queda, por improbable que
parezca, es la verdad.
  Sherlock Holmes

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

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

[Dmitry Shachnev]

Hi Rohan!

On Tue, Nov 27, 2018 at 04:24:43PM +0100, Rohan Garg wrote:
> [...]
>
> I concur here. It was correctly pointed out in another reply that by using
> OpenGL we're specifically catering to software that doesn't support
> GLES while making performance worse for mature applications that
> do implement both OpenGL and GLES. The reality of the situation is that
> the market currently favors GLES over GL on ARM SBC's, delivered with
> proprietary blobs. I think a more pragmatic view of this reality would be to
> deliver the best FOSS user experience that's possible with the proprietary
> drivers while the open source drivers are being improved. To that extent,
> by switching to GLES we improve the overall situation since OpenGL
> applications can fall back to software rendering via mesa on platforms
> where mesa does not support the GPU.

Here I agree with Luke Kenneth Casson Leighton’s opinion [1].

I think we should aim to provide the best possible experience with the free
software ecosystem. The experience with proprietary drivers should be the
second priority, if priority at all.

> By choosing to build Qt with GLES on ARM64, we make Debian a more
> attractive platform for vendors who'd like to target ARM64 boards.

We should make it attractive for vendors to release their code under
a free software (DFSG) license. That way anyone would be able to hack on it
and add missing support for a different OpenGL variant, if needed.

That said, as Lisandro announced, we will be happy to make any decision
if there is either a consensus or a TC decision about it.

[1]: https://lists.debian.org/debian-devel/2018/11/msg00622.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

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

[Rohan Garg]

Hey

On Mon, Nov 26, 2018 at 12:38 PM Raphael Hertzog  wrote:
>
> Hello Lisandro,
>
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution, but I
> believe you took the wrong decision. Please consider deferring the
> decision to the technical committe by seeking his advice (point 6.1.3
> of the constitution https://www.debian.org/devel/constitution.en.html#item-6).
>

Having worked on multiple ARM boards over the past 3 years,
I agree very strongly with Raphael.

> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
>
> I'm not pleased with how this discussion was handled. First of all,
> you did not leave enough time for all stakeholders to participate in
> the discussion (started on November 22th, closed November 25th, 3 days,
> that's not a reasonable timeframe in particular when 2 of the 3 days
> 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.
>

As the person who opened #881333, I completely agree. I've been on vacation
the past 10 days and haven't had a opportunity to chime in.

> 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.
>

I've had multiple concrete projects involving KDE, Qt and ARM over the past
few years, over multiple ARM platforms such as the ODROID C1, C2 and the
Pinebook. With my KDE hat on, we have a strong stake in having Plasma
perform decently well on these devices.

> Then I have read the whole discussion and I don't have the feeling that
> any consensus has been reached. It was largely driven by Andy Simpkins
> who explained his "gut feeling" as a tinkerer of arm* boards/devices and
> Bret Curtis who contributes to some applications with very specific OpenGL
> needs. While I value their contribution to the discussion, they both
> represent very specific classes of users.
>
> What I remember from this discussion is that the Windows build of Qt
> use GLES 2 by default. It would have been interesting to find out the
> rationale for this... because maybe the right decision for us would be
> to switch to GLES 2 by default as well (on all architectures as jcristau
> suggested). Someone else who likely also tried to ensure Qt for Windows is
> usable on most hardware made that choice.
>
> We got confirmation from many persons that almost all cards benefitting
> from Desktop OpenGL would also work with OpenGL ES. So in terms of
> hardware support, picking OpenGL ES is the right choice. In terms of
> sofware support, it looks like that Desktop OpenGL is better as there
> are a few applications that only work with Desktop OpenGL.
>
> 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.
>

I concur here. It was correctly pointed out in another reply that by using
OpenGL we're specifically catering to software that doesn't support
GLES while making performance worse for mature applications that
do implement both OpenGL and GLES. The reality of the situation is that
the market currently favors GLES over GL on ARM SBC's, delivered with
proprietary blobs. I think a more pragmatic view of this reality would be to
deliver the best FOSS user experience that's possible with the proprietary
drivers while the open source drivers are being improved. To that extent,
by switching to GLES we improve the overall situation since OpenGL
applications can fall back to software rendering via mesa on platforms
where mesa does not support the GPU.

> When taking all this into account, I believe that the right solution is
> to use OpenGL ES on all architectures. This will provide the required
> incentives for application developers who stick only to Desktop OpenGL
> to support OpenGL ES (even it it's at the cost of using some intermediary
> layer like https://github.com/p3/regal) and would maximize hardware
> support on all architectures.
>
> That said, I'm fine with a decision to change only arm64 since that's
> an architecture were devices that support only OpenGL ES are in the
> majority.
>

By choosing to build Qt with GLES on ARM64, we make Debian a more
attractive platform for vendors who'd like to target ARM64 boards.

Cheers
Rohan Garg

Bug#881333: 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

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 26 de noviembre de 2018 14:21:25 -03 Alan Corey escribió:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program?

It's a Qt build-time option. This in an upstream choice, not ours and not up 
to us to fix.

> Supply both libraries?

Already answered in the thread.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

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

[Alan Corey]

Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
compile your program?  Supply both libraries?  ES gives an enormous
performance boost to little machines that need it, desktop OpenGL is
more pretty pictures.

On 11/26/18, Lisandro Damián Nicanor Pérez Meyer  wrote:
> El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
>> Hello Lisandro,
>>
>> TLDR: thank you for starting this discussion, it was required as it's not
>> an easy decision to take as there is no realistic perfect solution,
>
> Our (team-wide) pleasure. This is something we have been digging since
> 2015.
>
>> but I
>> believe you took the wrong decision. Please consider deferring the
>> decision to the technical committe by seeking his advice (point 6.1.3
>> of the constitution
>> https://www.debian.org/devel/constitution.en.html#item-6).
>
> Will "kind of" do. Read below.
>
>
>> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
>> > It seems now clear that the general consensus seems to expect:
>> > = Qt available for both Desktop and ES OpenGL flavours
>> > = If no change is possible, keep arm64 with Desktop OpenGL support
>>
>> I'm not pleased with how this discussion was handled. First of all,
>> you did not leave enough time for all stakeholders to participate in
>> the discussion (started on November 22th, closed November 25th, 3 days,
>> that's not a reasonable timeframe in particular when 2 of the 3 days
>> were in the week-end).
>
> My most sincere apologies if our timeframe do not fit yours.
>
> Now, wrt the decision: clearly the situation is very complex, involving many
>
> different kinds of arm64 devices, drivers, libraries et all. People involved
>
> have different opinions. We so far have been the proxy between them, be it
> on
> bugs, IRC or whatever other channels our users have to contact us. We prefer
>
> not to be this proxy anymore (again, read below).
>
> Besides we (Qt's team) have just learned that the Desktop/ES support is not
>
> tied to the hardware but to the driver. That's a particularly interesting
> point.
>
> So:
>
> To quote my original mail, the "Qt available for both Desktop and ES OpenGL
>
> flavours" point remains unchanged: if someone wants to make it happen [s]he
>
> must join the team and support it from the inside. Remember there are little
>
> chances for this to happen in time for Buster.
>
> For the second point, "If no change is possible, keep arm64 with Desktop
> OpenGL support", we have this position: we will keep the status quo,
> deferring
> users who want GLES support to Ubuntu.
>
> *But* we are open to change this for any arch (read it: support either one
> or
> the other technology) as long as the decision is taken by the technical
> committee. As I wrote before, we will keep the status quo, so if anyone is
> interested in any change feel free to contact the TC.
>
> Regards, Lisandro.
>
> --
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

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

[Lisandro Damián Nicanor Pérez Meyer]

El lunes, 26 de noviembre de 2018 08:37:57 -03 Raphael Hertzog escribió:
> Hello Lisandro,
> 
> TLDR: thank you for starting this discussion, it was required as it's not
> an easy decision to take as there is no realistic perfect solution,

Our (team-wide) pleasure. This is something we have been digging since 2015.

> but I
> believe you took the wrong decision. Please consider deferring the
> decision to the technical committe by seeking his advice (point 6.1.3
> of the constitution
> https://www.debian.org/devel/constitution.en.html#item-6).

Will "kind of" do. Read below.


> On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> > It seems now clear that the general consensus seems to expect:
> > = Qt available for both Desktop and ES OpenGL flavours
> > = If no change is possible, keep arm64 with Desktop OpenGL support
> 
> I'm not pleased with how this discussion was handled. First of all,
> you did not leave enough time for all stakeholders to participate in
> the discussion (started on November 22th, closed November 25th, 3 days,
> that's not a reasonable timeframe in particular when 2 of the 3 days
> were in the week-end).

My most sincere apologies if our timeframe do not fit yours.

Now, wrt the decision: clearly the situation is very complex, involving many 
different kinds of arm64 devices, drivers, libraries et all. People involved 
have different opinions. We so far have been the proxy between them, be it on 
bugs, IRC or whatever other channels our users have to contact us. We prefer 
not to be this proxy anymore (again, read below).

Besides we (Qt's team) have just learned that the Desktop/ES support is not 
tied to the hardware but to the driver. That's a particularly interesting 
point.

So:

To quote my original mail, the "Qt available for both Desktop and ES OpenGL 
flavours" point remains unchanged: if someone wants to make it happen [s]he 
must join the team and support it from the inside. Remember there are little 
chances for this to happen in time for Buster.

For the second point, "If no change is possible, keep arm64 with Desktop 
OpenGL support", we have this position: we will keep the status quo, deferring 
users who want GLES support to Ubuntu.

*But* we are open to change this for any arch (read it: support either one or 
the other technology) as long as the decision is taken by the technical 
committee. As I wrote before, we will keep the status quo, so if anyone is 
interested in any change feel free to contact the TC.

Regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

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

[Riku Voipio]

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.

Riku

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

[Jonas Smedegaard]

Quoting Raphael Hertzog (2018-11-26 12:37:57)
> 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.

Is some _hardware_ really "designed for OpenGL ES only"?

I guess you mean that some hardware is only supported by non-free 
firmware/software hardcoded which is designed for OpenGL ES only".


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

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

[Raphael Hertzog]

Hello Lisandro,

TLDR: thank you for starting this discussion, it was required as it's not
an easy decision to take as there is no realistic perfect solution, but I
believe you took the wrong decision. Please consider deferring the
decision to the technical committe by seeking his advice (point 6.1.3
of the constitution https://www.debian.org/devel/constitution.en.html#item-6).

On Sun, 25 Nov 2018, Lisandro Damián Nicanor Pérez Meyer wrote:
> It seems now clear that the general consensus seems to expect:
> = Qt available for both Desktop and ES OpenGL flavours
> = If no change is possible, keep arm64 with Desktop OpenGL support

I'm not pleased with how this discussion was handled. First of all,
you did not leave enough time for all stakeholders to participate in
the discussion (started on November 22th, closed November 25th, 3 days,
that's not a reasonable timeframe in particular when 2 of the 3 days
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.

Then I have read the whole discussion and I don't have the feeling that
any consensus has been reached. It was largely driven by Andy Simpkins
who explained his "gut feeling" as a tinkerer of arm* boards/devices and
Bret Curtis who contributes to some applications with very specific OpenGL
needs. While I value their contribution to the discussion, they both
represent very specific classes of users.

What I remember from this discussion is that the Windows build of Qt
use GLES 2 by default. It would have been interesting to find out the
rationale for this... because maybe the right decision for us would be
to switch to GLES 2 by default as well (on all architectures as jcristau
suggested). Someone else who likely also tried to ensure Qt for Windows is
usable on most hardware made that choice.

We got confirmation from many persons that almost all cards benefitting
from Desktop OpenGL would also work with OpenGL ES. So in terms of
hardware support, picking OpenGL ES is the right choice. In terms of
sofware support, it looks like that Desktop OpenGL is better as there
are a few applications that only work with Desktop OpenGL.

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.

When taking all this into account, I believe that the right solution is
to use OpenGL ES on all architectures. This will provide the required
incentives for application developers who stick only to Desktop OpenGL
to support OpenGL ES (even it it's at the cost of using some intermediary
layer like https://github.com/p3/regal) and would maximize hardware
support on all architectures.

That said, I'm fine with a decision to change only arm64 since that's
an architecture were devices that support only OpenGL ES are in the
majority.

This is not a easy decision to make but we have a dedicated body to help
maintainers find the best technical decision when there are pros/cons
in both solutions, it's called the technical committee. Please consider
seeking their advice before taking your decision.

> Both Dmitry and I just learned that the RPI has the VC4 driver which enables 
> it to do hardware acceleration for Desktop OpenGL, we must admit that this is 
> a game changer in many ways, even if we are talking on just one board (but 
> quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use 
> Ubuntu.

I don't see why this affects the decision in any way. AFAIK the VC4 driver
also enables hardware acceleration for OpenGL ES. And this is only
relevant for the RPI3 which is the only arm64 hardware.

Bret Curtis clearly explained that we do get good performances on older
RPI (armhf-based) precisely because of the VC4 driver being able to
leverage OpenGL ES too.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

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

[Paul Wise]

On Sun, Nov 25, 2018 at 8:58 PM Lisandro Damián Nicanor Pérez Meyer wrote:

> Both Dmitry and I just learned that the RPI has the VC4 driver which enables
> it to do hardware acceleration for Desktop OpenGL, we must admit that this is
> a game changer in many ways, even if we are talking on just one board (but
> quite an ubiquitous one).

I expect this also applies to any driver in (or soon to be in) mesa,
including freedreno (Qualcomm), panfrost (Mali), lima (Mali), Etnaviv
(Vivante), Tegra etc. Drivers only supporting GLES seems to be a
something that happens only with the proprietary drivers. I don't have
any ARM devices with GPUs to be able to test this though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

[Lisandro Damián Nicanor Pérez Meyer]

Hi everyone!

We the Qt maintainers have reached a decision with respect to this topic. We 
reached debian-devel in order to get an idea of what other fellow Debian users 
and developers think of this subject. We would *really* like to thank you all 
for chiming in and discussing this in quite a nice way. Yes, most of us have 
strong positions, but even then the discussion was both civil and fruitful. So 
again, thanks to you all!

It seems now clear that the general consensus seems to expect:

= Qt available for both Desktop and ES OpenGL flavours

As we tried hard to explain this is really not easy nor even supported by 
upstream. But of course, if someone thinks [s]he wants to take the effort then 
[s]he's more than welcomed to joining the team. You will certainly need C++ 
library packaging skills and a *whole lot* of free time and build power. Due 
to the nature of this change, if the goal is achieved, it will be certainly 
targeted for Buster+1.

= If no change is possible, keep arm64 with Desktop OpenGL support

That seems to be what most of you want, and to say the truth, the easiest for 
us: we just keep status quo, no transition needed. We just package the next 
point release, check for bugs and mostly be done for Buster. So this is the 
approach we will take.

Both Dmitry and I just learned that the RPI has the VC4 driver which enables 
it to do hardware acceleration for Desktop OpenGL, we must admit that this is 
a game changer in many ways, even if we are talking on just one board (but 
quite an ubiquitous one). People wanting Qt+GLES on arm64 can always use 
Ubuntu.

For the Qt side of the Qt/KDE Team,

Lisandro

People reading the bug: please see

  

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.