On 2/28/17 8:12 AM, Hardening wrote:
> This has been done a quite long time ago, here =>
> https://gitorious.org/weston/jonseverinsson-weston/?p=weston:jonseverinsson-weston.git;a=commit;h=9e26d9356255f4af1723700272805f6d356c7d7a
>
> It's clearly outdated, and IIRC people here didn't like the way
Le 24/02/2017 à 00:51, DRC a écrit :
> On 12/15/16 3:01 AM, Pekka Paalanen wrote:
>> The current RDP-backed is written to set up and use only the Pixman
>> renderer. Pixman renderer is a software renderer, and will not
>> initialize EGL in the compositor. Therefore no support for hardware
>> accele
On 24 February 2017 at 09:36, Pekka Paalanen wrote:
> On Thu, 23 Feb 2017 17:51:24 -0600
> DRC wrote:
>
>> On 12/15/16 3:01 AM, Pekka Paalanen wrote:
>> > The current RDP-backed is written to set up and use only the Pixman
>> > renderer. Pixman renderer is a software renderer, and will not
>> > i
On Thu, 23 Feb 2017 17:51:24 -0600
DRC wrote:
> On 12/15/16 3:01 AM, Pekka Paalanen wrote:
> > The current RDP-backed is written to set up and use only the Pixman
> > renderer. Pixman renderer is a software renderer, and will not
> > initialize EGL in the compositor. Therefore no support for hard
On Fri, 24 Feb 2017 02:20:08 +0100
Christian Stroetmann wrote:
> Maybe a look on another compositor or the IVI shell might help you.
Please do not look at the IVI shell. It has nothing to do with this
while being an example of a... "inferior" window management
architecture dictated by GENIVI.
-- Forwarded message --
From: Erik De Rijcke
Date: 2017-02-24 8:46 GMT+01:00
Subject: Re: Remote display with 3D acceleration using Wayland/Weston
To: Christian Stroetmann
I made a poc for a remote (gl) display some time ago for my own compositor,
but instead of using rdp, I
On the 24th of February 2017 00:51, DRC wrote:
On 12/15/16 3:01 AM, Pekka Paalanen wrote:
The current RDP-backed is written to set up and use only the Pixman
renderer. Pixman renderer is a software renderer, and will not
initialize EGL in the compositor. Therefore no support for hardware
acceler
On the 24th of February 2017 00:51, DRC wrote:
On 12/15/16 3:01 AM, Pekka Paalanen wrote:
The current RDP-backed is written to set up and use only the Pixman
renderer. Pixman renderer is a software renderer, and will not
initialize EGL in the compositor. Therefore no support for hardware
acceler
On 12/15/16 3:01 AM, Pekka Paalanen wrote:
> The current RDP-backed is written to set up and use only the Pixman
> renderer. Pixman renderer is a software renderer, and will not
> initialize EGL in the compositor. Therefore no support for hardware
> accelerated OpenGL gets advertised to clients, an
On Mon, 19 Dec 2016 13:23:26 -0600
DRC wrote:
> On 12/19/16 2:48 AM, Pekka Paalanen wrote:
> > Hmm, indeed, maybe it would be possible if you are imposing your own
> > EGL middle-man library between the application and the real EGL library.
> >
> > That's definitely a idea to look into. I cannot
On 12/19/16 2:48 AM, Pekka Paalanen wrote:
> Hmm, indeed, maybe it would be possible if you are imposing your own
> EGL middle-man library between the application and the real EGL library.
>
> That's definitely a idea to look into. I cannot say off-hand why it
> would not work, so maybe it can wor
On Mon, 19 Dec 2016 10:50:22 +0100
Christian Stroetmann wrote:
> On19.Dec.2016 09:48, Pekka Paalanen wrote:
> > Sorry for not realizing the "wrap libEGL.so" approach earlier.
>
> Yeah, and how does this look like when put in context with Waltham?
It has nothing to do with Waltham at all. It is
On19.Dec.2016 09:48, Pekka Paalanen wrote:
On Fri, 16 Dec 2016 11:35:48 -0600
DRC wrote:
On 12/16/16 3:06 AM, Pekka Paalanen wrote:
I should probably tell a little more, because what I explained above is
a simplification due to using a single path for all buffer types.
...
Thanks again. Thi
On19.Dec.2016 09:48, Pekka Paalanen wrote:
On Fri, 16 Dec 2016 11:35:48 -0600
DRC wrote:
On 12/16/16 3:06 AM, Pekka Paalanen wrote:
I should probably tell a little more, because what I explained above is
a simplification due to using a single path for all buffer types.
...
Thanks again. Th
On Fri, 16 Dec 2016 11:35:48 -0600
DRC wrote:
> On 12/16/16 3:06 AM, Pekka Paalanen wrote:
> > I should probably tell a little more, because what I explained above is
> > a simplification due to using a single path for all buffer types.
> > ...
>
> Thanks again. This is all very new to me, an
On 12/16/16 3:06 AM, Pekka Paalanen wrote:
> I should probably tell a little more, because what I explained above is
> a simplification due to using a single path for all buffer types.
> ...
Thanks again. This is all very new to me, and I guess I don't fully
understand where these buffer types wo
On Thu, 15 Dec 2016 09:55:44 -0600
DRC wrote:
> On 12/15/16 3:01 AM, Pekka Paalanen wrote:
> > I assure you, this is a limitation of the RDP-backend itself. Nothing
> > outside of Weston creates this restriction.
> >
> > The current RDP-backed is written to set up and use only the Pixman
> > ren
On 12/15/16 3:01 AM, Pekka Paalanen wrote:
> I assure you, this is a limitation of the RDP-backend itself. Nothing
> outside of Weston creates this restriction.
>
> The current RDP-backed is written to set up and use only the Pixman
> renderer. Pixman renderer is a software renderer, and will not
On Wed, 14 Dec 2016 11:42:54 -0600
DRC wrote:
> But if you run OpenGL applications in Weston, as it is currently
> implemented, then the OpenGL applications are either GPU-accelerated or
> not, depending on the back end used. If you run Weston nested in a
> Wayland compositor that is already GPU
On 12/14/16 8:52 PM, Carsten Haitzler (The Rasterman) wrote:
> weston is not the only wayland compositor. is the the sample/test compositor.
> wayalnd does not mean sticking to just what weston does.
>
> i suspect weston's rdp back-end forces a sw gl stack because it's easier to be
> driver agnost
On Wed, 14 Dec 2016 11:42:54 -0600 DRC said:
...snip...
> Again, not how it currently works when using Weston with the RDP back end.
weston is not the only wayland compositor. is the the sample/test compositor.
wayalnd does not mean sticking to just what weston does.
i suspect weston's rdp bac
On 12/14/16 3:27 AM, Pekka Paalanen wrote:
> could you be more specific on what you mean by "server-side", please?
> Are you referring to the machine where the X server runs, or the
> machine that is remote from a user perspective where the app runs?
Few people use remote X anymore in my industry,
On Tue, 13 Dec 2016 14:39:31 -0600
DRC wrote:
> Greetings. I am the founder and principal developer for The VirtualGL
> Project, which has (since 2004) produced a GLX interposer (VirtualGL)
> and a high-speed X proxy (TurboVNC) that are widely used for running
> Linux/Unix OpenGL applications re
On 13.Dec.2016 21:39, DRC wrote:
I thought about this on the 14th of March 2014 (see also [1]).
Have you looked at https://github.com/waltham/waltham ?
Regards
Christian Stroetmann
[1] OntoGraphics
(www.ontolinux.com/technology/ontographics/ontographics.htm)
Greetings. I am the founder a
Greetings. I am the founder and principal developer for The VirtualGL
Project, which has (since 2004) produced a GLX interposer (VirtualGL)
and a high-speed X proxy (TurboVNC) that are widely used for running
Linux/Unix OpenGL applications remotely with hardware-accelerated
server-side 3D renderin
25 matches
Mail list logo
