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