2014/1/13 Thomas Lübking <thomas.luebk...@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 libplasma
> 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 downstream
> (and on top of that, current QML usage might still kick in libplasma->libGL)
>
> 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 - but
> 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 subset, then i'm golden :) I'll try LD_PRELOAD trick. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
