Hello,
On Thu, 29 Nov 2018, Adrian Bunk wrote:
> Qt already supports runtime ES/non-ES in the same library build on
> Windows [2], something like that might also be doable for Linux if
> anyone (Linaro? Canonical?) with a real interest in that would work
> on making it happen.
>
> Some of the
On Wed, Nov 28, 2018 at 12:32:51PM -0800, Steve Langasek wrote:
> I would caution against prematurely optimizing for build-time. Yes,
> building the entire source package twice is a waste of resources, but it's
> probably a drop in the bucket.
My mail concert was not build-time, but our
On Wed, Nov 28, 2018 at 11:46:21PM +0200, Adrian Bunk wrote:
> On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
> >...
> > Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> > stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
> >...
>
On 2018-11-27 21:19 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > prepare dual stack packages that use the symbols file magic from
> > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> >
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> > $ grep-dctrl -n -sSource:Package -FDepends \
> > -e
> > 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> >
On Tue, Nov 27, 2018 at 02:06:27PM -0800, Steve Langasek wrote:
>...
> Hmm, so I'm not sure this reflects the actual state of the art wrt dual Qt
> stacks as it existed in Ubuntu at the time Ubuntu Touch was sunsetted.
>...
Is there some rationale documented somewhere why this wasn't used in
On Wed, Nov 28, 2018 at 05:03:51PM +0300, Dmitry Shachnev wrote:
> On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> The amount of packages will probably be larger in the current sid,
> but it should not be more than 20 packages.
> Plus there are packages which are using
El miércoles, 28 de noviembre de 2018 12:17:22 -03 Julien Cristau escribió:
> [dropping -devel, adding mesa and kde maintainers instead]
ACK.
> On 11/27/18 5:42 PM, Steve Langasek wrote:
> > On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> >> Steve Langasek writes:
> >>> Long
[dropping -devel, adding mesa and kde maintainers instead]
On 11/27/18 5:42 PM, Steve Langasek wrote:
> On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
>> Steve Langasek writes:
>
>>> Long ago I heard rumors of development work on mesa that would allow it to
>>> function as a
On Tue, Nov 27, 2018 at 11:00:52PM -0800, Steve Langasek wrote:
> $ grep-dctrl -n -sSource:Package -FDepends \
> -e
> 'libqt5(gui|3drenderer|quick|quickparticles|quickwidgets|multimediawidgets)5[[:space:]]*(\(>=
> 5\.[0-9.]*\))(?|$),' \
>
>
Hi Steve and all,
On Tue, Nov 27, 2018 at 03:39:58PM -0800, Steve Langasek wrote:
> It is actually fairly easy to answer this question as well: simply identify
> all the packages in the archive that depend on one of the known dual-stack
> libraries, prepare dual stack packages that use the
Hi Steve!
El miércoles, 28 de noviembre de 2018 04:00:52 -03 Steve Langasek escribió:
[snip]
> > At this point I really feel that, except I am missing something, double
> > building is just not a good idea :-/
>
> Ok, I don't think you've understood then. Perhaps a further example from
> the
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
On Tue, Nov 27, 2018 at 10:13:06PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
> Meyer escribió:
> [snip]
> > > > prepare dual stack packages that use the symbols file magic from
> > > > Ubuntu, rebuild all the
El martes, 27 de noviembre de 2018 21:51:47 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
[snip]
> > > prepare dual stack packages that use the symbols file magic from
> > > Ubuntu, rebuild all the reverse-dependencies, and identify all those
> > > packages which are libraries and which end
El martes, 27 de noviembre de 2018 21:19:20 -03 Lisandro Damián Nicanor Pérez
Meyer escribió:
> El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> > On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
>
> Meyer wrote:
> [snip]
>
> > > Yes, we are :-)
El martes, 27 de noviembre de 2018 20:39:58 -03 Steve Langasek escribió:
> On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez
Meyer wrote:
[snip]
> > Yes, we are :-) Dmitry has been working on them (he is also an Ubuntu Qt
> > maintainer). He points me out that those 7
On Tue, Nov 27, 2018 at 07:58:17PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> > https://launchpad.net/ubuntu/+source/qtbase-opensource-src-gles/5.7.1+dfsg->
> > 2ubuntu4~1
> > And here is the list of all packages that required dual-stack at least as of
> > 2017, when Ubuntu stopped
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
Hi Lisandro,
On Fri, Nov 23, 2018 at 11:05:11PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Andy: explicitly CCing you because I think it answers part of a question you
> did but in another part of the thread.
> El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre 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
>
On Mon, Nov 26, 2018 at 03:39:03PM -0800, Keith Packard wrote:
> Steve Langasek writes:
> > Long ago I heard rumors of development work on mesa that would allow it to
> > function as a proxy library, so that apps would link against libGL as needed
> > and the GL implementation would use a
> The reality of the situation is that the market currently favors GLES
> over GL on ARM SBC's, delivered with proprietary blobs.
Not sure which market you're talking about, but this "reality" is
a problem for Debian.
> the best FOSS user experience that's possible with the proprietary drivers
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
Hi,
On 2018-11-27 02:46 +, Wookey wrote:
> >
> > Well, that's at very least an interesting data point. So yes, they exist,
> > but
> > they are new and expensive. Can I assume that this means most of our arm64
> > users do not yet get to them?
> Not yet, no although I think you can just
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
Hi,
On 26/11/18 8:58 pm, Riku Voipio wrote:
> On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
>
>> The real issue here is that *many* arm64 boards currently do not support
>>
On Tue, Nov 27, 2018 at 7:54 AM Gene Heskett wrote:
> Not in that light, but would sinking the pi foundation make us look any
> better? I think not.
the rule i go by is that of the "bill of ethics" [1] - which is both
simple and puzzling at the same time. if you're familiar with the
"New Law"
On Tuesday 27 November 2018 02:04:33 Luke Kenneth Casson Leighton wrote:
> On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett
wrote:
> > On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton
wrote:
> > > On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez
> > > Meyer
> > >
> >
On Tue, Nov 27, 2018 at 6:47 AM Gene Heskett wrote:
>
> On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote:
>
> > On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
> >
> > wrote:
> > > So: what's the best outcome for our *current* users? Again, pick
> > >
On Monday 26 November 2018 22:04:04 Luke Kenneth Casson Leighton wrote:
> On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
>
> wrote:
> > So: what's the best outcome for our *current* users? Again, pick
> > only one.
>
> here's a perspective that may not have been considered:
On Fri, Nov 23, 2018 at 12:18 AM Lisandro Damián Nicanor Pérez Meyer
wrote:
> So: what's the best outcome for our *current* users? Again, pick only one.
here's a perspective that may not have been considered: how much
influence and effect on purchasing decisions would the choice made
have?
we
On 2018-11-23 23:10 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> >
> > My main desktop is now an arm64 machine with an nvidia PCI graphics
> > card. These are fairly new (and currently expensive), but I have
> > reason to
On Mon, Nov 26, 2018 at 12:21:25PM -0500, Alan Corey wrote:
> Why couldn't you choose QT for Desktop or QT for ES OpenGL when you
> compile your program? Supply both libraries?
Because this requires providing two separate *stacks* of source packages,
one for GL and one for GLES, which from
On Monday 26 November 2018 16:16:40 Alan Corey wrote:
> I think not pulling it to full screen puts everybody in the same boat
> by using the default size.
It also hands you figures not achievable in the real world, often off by
20x.
> But I can watch videos with smplayer on my
> Rock64, on a
I think not pulling it to full screen puts everybody in the same boat
by using the default size. But I can watch videos with smplayer on my
Rock64, on a Pi I need to use omxplayer because smplayer is too low.
There was some mention on the pine64.org page about using the Rock64
as a multimedia
On Monday 26 November 2018 09:40:34 Alan Corey wrote:
> Try glxgears and es2gears on few different platforms. On a Pi 3b
> glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
> it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
> screen HD video while the CPU
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
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,
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
Try glxgears and es2gears on few different platforms. On a Pi 3b
glxgears runs at about 45 FPS, es2gears slightly lower. On my Rock64
it's in the hundreds of FPS but that's Mali. Look at omxplayer, full
screen HD video while the CPU idles (on a Pi). The GPU is more
capable than the CPU. You
Hello Ian,
On Mon, Nov 26, 2018 at 2:04 PM Ian Campbell wrote:
>
> On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> > The hardware that supports GLES also supports OpenGL because GLES is
> > a subset of OpenGL.
>
> I'm confused by this inference. If GLES is a subset of OpenGL then
>
On Mon, 2018-11-26 at 12:07 +0100, bret curtis wrote:
> The hardware that supports GLES also supports OpenGL because GLES is
> a subset of OpenGL.
I'm confused by this inference. If GLES is a subset of OpenGL then
surely hardware which claims to implement GLES is at liberty to only
implement that
>> 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
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
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
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
Hi!
On Mon, Nov 26, 2018 at 11:40 AM Raphael Hertzog wrote:
> >
> > What applications does Debian have in its repo that only support GLES?
>
> Wrong question. Maybe it makes sense for you at the application level for
> the application that are hooking into OpenGL directly. But we are speaking
>
> On Sat, 24 Nov 2018, bret curtis wrote:
> > This is a very wrong assumption, the OpenGL on a RPi (all of them) is
> > hardware accelerated via the VC4 mesa driver by Eric Anholt which is
> > shipped, by default, on by Raspbian. It supports up to OpenGL 2.1 and
> > if you plan on having hardware
Hello,
On Sat, 24 Nov 2018, bret curtis wrote:
> Moving Qt back to using Desktop GL from GLES is going to have zero
> impact performance on the RPi since the VC4 supports up to OpenGL 2.1
> and and GLES 2.0 [1]
That's a different claim to what you made in a former message.
> The problem is that
On Thu, Nov 22, 2018 at 07:14:44PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 18:30:39 -03 Marcin Juszkiewicz escribió:
> > Does it mean that arm64 box with PCI Express graphics card will be not
> > able to use Qt based software? I can put Radeon or
Hi,
On Fri, 23 Nov 2018, Dmitry Shachnev wrote:
> According to config_help.txt [1], Qt uses ES2 by default on Windows.
Interesting.
> But as Lisandro says, such a change in Debian will break many packages
> (which are currently broken on ARM only), so we are definitely not
> considering it at
On Mon, Nov 26, 2018 at 11:09 AM Gene Heskett wrote:
> And in what repo might I find this panfrost thingy for stretch?
>
> > lima (Mali),
>
> Or this one?
Neither of these projects have a mainline mesa driver yet, they are
both are in the reverse engineering and driver development phase.
On Sunday 25 November 2018 19:18:39 Paul Wise wrote:
> 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
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
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
On Saturday 24 November 2018 14:36:11 bret curtis wrote:
> > > There are more than 5 million Raspberry Pis were sold as of
> > > February 2015. All of them with a VC4 GPU, Raspbian ships with the
> > > VC4 mesa driver enabled!
> > >
> > > I'm of the opinion that the switch away from Desktop
Hey Scott,
On Sat, Nov 24, 2018 at 9:01 PM Scott Kitterman wrote:
>
> On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
>
> We have a Rasberry Pi working as a desktop here at my house. It's quite
> usable as long as you only try to do a few things at a time, but it's not by
> any
On Saturday, November 24, 2018 08:36:11 PM bret curtis wrote:
> > > There are more than 5 million Raspberry Pis were sold as of February
> > > 2015.
> > > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > > enabled!
> > >
> > > I'm of the opinion that the switch away from
> >
> > There are more than 5 million Raspberry Pis were sold as of February 2015.
> > All of them with a VC4 GPU, Raspbian ships with the VC4 mesa driver
> > enabled!
> >
> > I'm of the opinion that the switch away from Desktop OpenGL to GLES was a
> > huge mistake and should be reversed as soon
On Saturday 24 November 2018 10:29:08 Steve McIntyre wrote:
> On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote:
> >And the OpenGL driver is of zero use to me until a preemp-rt, or full
> >RTAI kernel accompanies it. Once that becomes available, and more
> > pi's are in the supply
On Sat, Nov 24, 2018 at 10:10:04AM -0500, Gene Heskett wrote:
>
>And the OpenGL driver is of zero use to me until a preemp-rt, or full
>RTAI kernel accompanies it. Once that becomes available, and more pi's
>are in the supply line, you will see an explosion of pi's running cnc
>machinery. Why?
On Saturday 24 November 2018 09:14:48 bret curtis wrote:
> > > But even here in this place I have seen *a lot* of "cheap" arm64
> > > boards. Yes, the RPI3[+] is ubiquitous. And having to render Open
> > > GL stuff by CPU is precisely not the fastest thing around.
> >
> > "I have a Raspberry Pi
El sábado, 24 de noviembre de 2018 11:23:51 -03 bret curtis escribió:
> Hello Lisandro!
>
> > Yes, that's a drawback we are not hiding. Applications needing Desktop
> > OpenGL would be left out. But...
>
> Sorry, but this is just not acceptable. There has to be another way.
>
> > > If you say
On 24/11/18 14:14, bret curtis wrote:
>>> But even here in this place I have seen *a lot* of "cheap" arm64 boards.
>>> Yes,
>>> the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
>>> precisely not the fastest thing around.
>>
>> "I have a Raspberry Pi (or similar mobile
Hello Lisandro!
> Yes, that's a drawback we are not hiding. Applications needing Desktop OpenGL
> would be left out. But...
>
Sorry, but this is just not acceptable. There has to be another way.
>
> > If you say that arm64 has to be GLESv2 as well, then that is yet another
> > arch that OpenMW
Hi Andy!
El sábado, 24 de noviembre de 2018 07:26:34 -03 Andy Simpkins escribió:
> On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Andy: explicitly CCing you because I think it answers part of a question
> > you did but in another part of the thread.
> >
> > El viernes, 23 de
> > But even here in this place I have seen *a lot* of "cheap" arm64 boards.
> > Yes,
> > the RPI3[+] is ubiquitous. And having to render Open GL stuff by CPU is
> > precisely not the fastest thing around.
>
> "I have a Raspberry Pi (or similar mobile class system that
> has migrated / is
On 2018-11-24, Andy Simpkins wrote:
> BOTH are possible so why dictate only one?
Because it would require two flavours of all users.
/Sune
On 24/11/2018 02:05, Lisandro Damián Nicanor Pérez Meyer wrote:
Andy: explicitly CCing you because I think it answers part of a question you
did but in another part of the thread.
El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
On Fri, Nov 23, 2018 at 03:27:57AM
Hi Bret!
El viernes, 23 de noviembre de 2018 11:14:34 -03 psi...@gmail.com escribió:
> Just chiming in here as package maintainer of an effected package, OpenMW
> and also an upstream developer of said software, along with contributor to
> OpenSceneGraph.
>
> Here are some related open bugs
El viernes, 23 de noviembre de 2018 09:23:29 -03 Dmitry Shachnev escribió:
> On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> > W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > > I would still like to know if the upcoming arm64 desktop devices have
> > > any problems
Hi Wookey!
El viernes, 23 de noviembre de 2018 12:26:49 -03 Wookey escribió:
> On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> > Hello,
> >
> > > - Qt is tied to either Desktop or GLES: yes
> > >
> > > So we need to pick one. The question is then which one will benefit our
> > >
Andy: explicitly CCing you because I think it answers part of a question you
did but in another part of the thread.
El viernes, 23 de noviembre de 2018 06:58:13 -03 Steve McIntyre escribió:
> On Fri, Nov 23, 2018 at 03:27:57AM +0300, Dmitry Eremin-Solenikov wrote:
[snip]
> >Can you build two
On 2018-11-23 03:27 +0300, Dmitry Eremin-Solenikov wrote:
> Hello,
> > - Qt is tied to either Desktop or GLES: yes
> >
> > So we need to pick one. The question is then which one will benefit our
> > users
> > most.
> >
> > So far I personally know 0 people with an arm64 board with PCI slots,
On 2018-11-23, Julien Cristau wrote:
> Why is it OK to break them on arm64 if it's not OK to break them on
> amd64? Do you have a list of those packages?
Because most people on arm64 don't have the hardware.
Rather give them fewer packages that works great rather than many
packages that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Just chiming in here as package maintainer of an effected package, OpenMW
and also an upstream developer of said software, along with contributor to
OpenSceneGraph.
Here are some related open bugs involving Qt and GLESv2 and arm*:
> Yeah - it depends exactly on your background. There's a small (but
> growing) set of arm64 desktop users,
Apparently none of them are here, tho.
> and it would be unfortunate to cut them off.
But would it? IIUC this proposed change only impacts Qt applications,
and it's not clear whether it
On Friday 23 November 2018 06:37:28 Dmitry Shachnev wrote:
> On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote:
> > I think a better question would be: Does it improve, or disable,
> > decent video support for the dozens of arm64 cards in the r-pi
> > format, such as the arm64 based
On Fri, Nov 23, 2018 at 01:08:03PM +0100, Marcin Juszkiewicz wrote:
> W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> > I would still like to know if the upcoming arm64 desktop devices have
> > any problems working with OpenGL ES.
>
> Arm64 desktop systems use Radeon or NVidia cards with same
On Fri, Nov 23, 2018 at 12:25:51PM +0100, Julien Cristau wrote:
> > According to config_help.txt [1], Qt uses ES2 by default on Windows.
> > It probably means that it will work fine with most desktop video cards.
> >
> > But as Lisandro says, such a change in Debian will break many packages
> >
W dniu 23.11.2018 o 13:00, Dmitry Shachnev pisze:
> I would still like to know if the upcoming arm64 desktop devices have
> any problems working with OpenGL ES.
Arm64 desktop systems use Radeon or NVidia cards with same opensource
drivers as x86-64 systems. So you can check how it goes with
On Fri, Nov 23, 2018 at 09:34:44AM +, Andy Simpkins wrote:
> I do understand that there would be a lot of effort required to support OGL
> and OGLES but as you have already pointed out "you are doing this already"
> because OGL is provided for all platforms except armel & armhf which have
>
On Thu, Nov 22, 2018 at 06:01:14PM -0500, Gene Heskett wrote:
> I think a better question would be: Does it improve, or disable, decent
> video support for the dozens of arm64 cards in the r-pi format, such as
> the arm64 based $44 rock64? [...]
As far as I know Raspberry Pi 3 and similar devices
On 11/23/18 12:18 PM, Dmitry Shachnev wrote:
> On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
>> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
>> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
>> architectures, to stop the special-casing
On Thu, Nov 22, 2018 at 11:05:27PM +0100, Julien Cristau wrote:
> At least mesa drivers can be used for desktop GL or GLESv2 just fine,
> AFAIK. Maybe the answer for Qt is to switch to GLESv2 for all
> architectures, to stop the special-casing madness, instead of making it
> spread? :)
According
Quoting John Paul Adrian Glaubitz :
Granted, I don’t really know what the real world distribution of
embedded and desktop/server/laptop devices of arm64 is. But I could
imagine that there will be more arm64 devices in the future which
are desktops, servers or laptops.
There is e.g. this
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
>:
>>
>> Hi! Please let me reply first to your last part:
>>
>> > Is there any possible way to support *BOTH* OpenGL / OpenGLES? Mutually
>> >
On Thursday 22 November 2018 19:17:29 Lisandro Damián Nicanor Pérez Meyer
wrote:
> 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
Hello,
пт, 23 нояб. 2018 г. в 03:18, Lisandro Damián Nicanor Pérez Meyer
:
>
> 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?
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
On Thursday 22 November 2018 17:27:35 Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau
escribió:
> > On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> > >> The Qt framework can be
On Thursday 22 November 2018 17:33:50 Lisandro Damián Nicanor Pérez Meyer
wrote:
> El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev
escribió:
> > Hi all!
> >
> > The Qt framework can be built either with “desktop” OpenGL, or with
> > OpenGL ES support. At the moment we are
El jueves, 22 de noviembre de 2018 15:37:29 -03 Dmitry Shachnev escribió:
> Hi all!
>
> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL
> ES support. At the moment we are building it with OpenGL ES on armel and
> armhf, and with desktop OpenGL on all other
El jueves, 22 de noviembre de 2018 19:05:27 -03 Julien Cristau escribió:
> On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> > W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> >> The Qt framework can be built either with “desktop” OpenGL, or with
> >> OpenGL ES support. At the moment we are
On 11/22/18 10:30 PM, Marcin Juszkiewicz wrote:
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with desktop OpenGL on all
> On Nov 22, 2018, at 10:30 PM, Marcin Juszkiewicz
> wrote:
>
> W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
>
>> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
>> support. At the moment we are building it with OpenGL ES on armel and armhf,
>> and with
W dniu 22.11.2018 o 19:37, Dmitry Shachnev pisze:
> The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
> support. At the moment we are building it with OpenGL ES on armel and armhf,
> and with desktop OpenGL on all other architectures.
>
> However we have received a
Hi all!
The Qt framework can be built either with “desktop” OpenGL, or with OpenGL ES
support. At the moment we are building it with OpenGL ES on armel and armhf,
and with desktop OpenGL on all other architectures.
However we have received a request [1] from two different persons to add arm64
to
99 matches
Mail list logo