Upcoming Qt switch to OpenGL ES on arm64

Steve McIntyre steve at einval.com
Fri Nov 23 09:58:13 GMT 2018


On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
>Hello,
>пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
><perezmeyer at gmail.com>:
>>
>> Hi! Please let me reply first to your last part:
>>
>> > Is there any possible way to support *BOTH* OpenGL / OpenGLES?  Mutually
>> > exclusive from an install POV, but give the end user the choice which to
>> > install?  Why should we have one Architecture forced down a path
>> > different to another architecture?
>>
>> No, I'm afraid there is no way to do that. We did consider it many times, but
>> is definitely too much work to hack on.
>>
>> So we need to force an architecture (actually, all of them!) to either one or
>> the other.
>
>Can you build two packages and allow user to select, which one he wants to
>install? Or those packages will be binary incompatible?

That's a good question, yes. It'w ahst I was wondering too.

...

>> So far I personally know 0 people with an arm64 board with PCI slots, while I
>> know many with arm64 boards with hardware GLES support.
>
>I'm working with big arm64 iron, so for me a server arm64 board with PCIe slots
>(and thus PCIe graphic cards) and on-board Aspeed "VGA card" is more common
>compared to GLES-enabled arm64 SoC.

Yeah - it depends exactly on your background. There's a small (but
growing) set of arm64 desktop users, and it would be unfortunate to
cut them off.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier




More information about the pkg-kde-talk mailing list