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 ago
[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 prox
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
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 tha
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
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 hardwar
> 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
W
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 deferrin
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 i
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 hardware-accelerated GLES driver where
> possible, falling back to software GL
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 Ubuntu
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, 26
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 d
>> 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
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 proje
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
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
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.
https:/
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 on
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 ni
22 matches
Mail list logo
