[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fwd: [kde] Bug#688801: kde-window-manager: Incorrect Build-conflict against libgles2-mesa-dev
From:       Held Bier <lausgans () gmail ! com>
Date:       2014-01-14 16:28:56
Message-ID: CANoehN_-mBwcUSNjB0TdyPusisMPSNGS23qn5Ah-1w-0O6wqpw () mail ! gmail ! com
[Download RAW message or body]

2014/1/13 Thomas L=FCbking <thomas.luebking@gmail.com>:
> On Montag, 13. Januar 2014 12:58:55 CEST, Myriam Schweingruber wrote:
>
>> This way i've got a kwin_gles also, thought ldd'ing on it showed that
>> besides libEGL dependency (which is good), it also relied on libGL
>> (which is not good! this means some/most of GL functions were still
>> used).
>
>
> kwin/_gles links libplasma which links libGL - you'd have to build plasma
> against GLES (while i'm not sure whether that's possible) or strip libpla=
sma
> deps from kwin - this should be the case for "plasma workspaces 2"("KDE
> notfive"), but libplasma might still be dlopened through qml (eventually
> including libGL)
> It's not trivial, but possible, for KDE SC4 (it's mostly used for
> effectframe styling - forcing them to be unstyled will get you > half the
> way) - but since workspace is frozen, this could only be applied downstre=
am
> (and on top of that, current QML usage might still kick in libplasma->lib=
GL)
>
> However, GLES is a subset of GL and kwin_gles only uses this subset, so if
> GLES is accelerated for you, LD_PRELOADing libGLES *might* do the job - b=
ut
> i've really no idea.
>
> Cheers,
> Thomas
>
> ps: despite "compiz", it's "compoSiting"

Thomas, thanks for the detailed answer! If kwin_gles only uses a GLES subse=
t,
then i'm golden :) I'll try LD_PRELOAD trick.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]