After digging enough to Render API and Window API, I know that I was wrong.
Wayland is here not for a performance reason, but to design a
windowing system in a right way.
X11 build a Render System inside Window System, and make the Render
System depend on Window System, which is plain wrong.
We c
On Fri, Jul 13, 2012 at 3:28 AM, Abhijit Potnis wrote:
> Hello ,
>
> Is there any plan to have(& maintain) a GLES2 >> framebuffer back-end for
> Weston on the weston git, so as to have Weston run on hardware's that do
> support GLES2 on framebuffer ?
> Say for example ARM targets like the beagle-b
Please Register!
Just to beat the drums a bit more and give you some updates:
Currently we have 16 registered participants for XDC 2012 in Nuernberg
there only 11 weeks until the event, so if you have not done so already:
- if you are on a corporate budget please ping your corpo
enter handler wasn't updating sprite coordinates based on the Wayland event
just sent, failing when forwarding the correct EnterNotify to the X client.
This should fix it.
Signed-off-by: Tiago Vignatti
---
hw/xfree86/xwayland/xwayland-input.c |5 +
1 file changed, 5 insertions(+)
diff -
hard debug shows it sigfaut at
EGLBoolean EGLAPIENTRY
eglQueryWaylandBufferWL(EGLDisplay dpy,struct wl_buffer *buffer,
EGLint attribute, EGLint *value)
{
_EGLDisplay *disp = _eglLockDisplay(dpy);
_EGLDriver *drv;
EGLBoolean ret;
_EGL_CHECK_DISPLAY(disp, EGL_FAL
the backtrace is:
(gdb) backtrace
#0 0x in ?? ()
#1 0x779b6653 in eglQueryWaylandBufferWL () from
/usr/lib64/libEGL.so.1
#2 0x00408a7a in weston_surface_attach (surface=0x8c8680,
buffer=0x8937c0) at compositor.c:778
#3 0x0040a79c in surface_attach (clien
On Fri, Jul 13, 2012 at 3:40 PM, Pekka Paalanen wrote:
> On Fri, 13 Jul 2012 15:20:22 +0530
> Abhijit Potnis wrote:
>
> > Hello Pekka
> >
> > Ya, I do agree. With GLES2-on-fb we would end up having an implementation
> > for each board or for a group of similar boards.
> >
> > My question is, ca
On Fri, 13 Jul 2012 15:20:22 +0530
Abhijit Potnis wrote:
> Hello Pekka
>
> Ya, I do agree. With GLES2-on-fb we would end up having an implementation
> for each board or for a group of similar boards.
>
> My question is, can it be possible that generic part of GLES2-on-fb be
> separated
> out a
Hello Pekka
On Fri, Jul 13, 2012 at 1:30 PM, Pekka Paalanen wrote:
> On Fri, 13 Jul 2012 12:58:45 +0530
> Abhijit Potnis wrote:
>
> > Hello ,
> >
> > Is there any plan to have(& maintain) a GLES2 >> framebuffer back-end for
> > Weston on the weston git, so as to have Weston run on hardware's th
On Fri, 13 Jul 2012 12:58:45 +0530
Abhijit Potnis wrote:
> Hello ,
>
> Is there any plan to have(& maintain) a GLES2 >> framebuffer back-end for
> Weston on the weston git, so as to have Weston run on hardware's that do
> support GLES2 on framebuffer ?
> Say for example ARM targets like the beag
Hello ,
Is there any plan to have(& maintain) a GLES2 >> framebuffer back-end for
Weston on the weston git, so as to have Weston run on hardware's that do
support GLES2 on framebuffer ?
Say for example ARM targets like the beagle-board. I know that the GLES2 >>
framebuffer implementations would be
Hi Nick,
On Thu, 12 Jul 2012 23:35:04 -0700
Mikalai Kisialiou wrote:
> Pekka,
>
> Thank you for your response. To clarify it, I am not developing another
> windowing interface that will compete with Weston or QT Compositor. My
If by windowing interface you mean a Wayland compositor, there is
n
Pekka,
Thank you for your response. To clarify it, I am not developing another
windowing interface that will compete with Weston or QT Compositor. My
application is completely different and the open source graphics driver
stack is the likely bottleneck. I'm not even sure that Mesa/Gallium can
give
13 matches
Mail list logo
