Re: Weston framerate (Re: bare bones opengl weston client sample)
the (window == NULL) was a remnant of prior experimentation. I have removed and confirmed There are no other eglSwapBuffer() calls anywhere in the code. I will produce a simple test app that illustrates my problem. Bottom line is: glut = 60 fps wayland = 20 fps Hopefully, in doing so, it will flush out what I am missing. Thanks again. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
Sorry about the delay.
I flew 8 legs in 4 days this week.
Here are the mains for both the glut and Wayland instance of my test
application.
uMfdInit, uMfdDraw, and c-controller-event() are the interface
functions, solely used by both implementations.
The code under the hood is IDENTICAL. (with the exception of
glutPostRedisplay() for pan gestures.)
In MainWayland you will see simple-egl.c conditionally compiled for my
application using
HAVE_GLES2 and SIMPLE_EGL
Both MainWayland.c and MainGlut.c use the functions above in the same way.
To recap I am hoping to allow unbounded redraws for testing purposes only.
MainGlut.c
code
#include uMfd.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include signal.h
extern UmfdContext *c;
void glutMotion(int x, int y)
{
c-controller-event(c, drag, x, y);
}
void glutMouse(int button, int state, int x, int y)
{
if (button == GLUT_LEFT_BUTTON)
{
if (state == GLUT_UP)
c-controller-event(c, leftUp, x, y);
else
c-controller-event(c, leftDown, x, y);
}
if (button == GLUT_RIGHT_BUTTON)
{
if (state == GLUT_UP)
c-controller-event(c, rightUp, x, y);
else
c-controller-event(c, rightDown, x, y);
}
}
void keyboardIn(unsigned char key, int x, int y)
{
fprintf(stderr, key-%x; x-%d; y-%d\n, 0x00ff key, x, y);
switch(key 0xff)
{
case GLUT_KEY_UP:
c-controller-event(c, upArrow, 0, 0);
break;
case GLUT_KEY_DOWN:
c-controller-event(c, downArrow, 0, 0);
break;
case GLUT_KEY_RIGHT:
c-controller-event(c, rightArrow, 0, 0);
break;
case GLUT_KEY_LEFT:
c-controller-event(c, leftArrow, 0, 0);
break;
// PC menu tooggle
case 0x1b:
fprintf(stderr, glut KB esc menu);
c-controller-event(c, menu, 0, 0);
break;
case '-':
case '_':
case 0x32:
c-controller-event(c, zoomOut, 2, 2);
break;
case '=':
case '+':
case 0x33:
c-controller-event(c, zoomIn, 3, 3);
break;
// PC menu select
case 0xa:
case 0xd:
fprintf(stderr, glut KB enter menu select\n);
c-controller-event(c, menuSelect, 0, 0);
break;
}
}
void glutDraw()
{
uMfdDraw(c);
}
void glutIdle()
{
uMfdProcess(c);
//uMfdDraw(c);
}
void glutResize(int width, int height)
{
c-view-resize(c, width, height);
}
int InitializeGraphics()
{
int argc= 0;
char *argv[] = {one, two};
fprintf(stderr, pc glut init\n);
glutInit(argc, argv);
/* defining the window with double buffer */
glutInitDisplayMode(GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH);
glutEnterGameMode();
if(0)
{
glutInitWindowSize(p.width, p.height);
glutInitWindowPosition(100, 100);
}
//glutFullScreen();
//glutCreateWindow(FBCB2 uMFD 'micro');
glutDisplayFunc(glutDraw);
glutMotionFunc(glutMotion);
glutPassiveMotionFunc(glutMotion);
glutMouseFunc(glutMouse);
glutIdleFunc(glutIdle);
glutSpecialFunc((void*)keyboardIn);
glutKeyboardFunc((void*)keyboardIn);
glutReshapeFunc(glutResize);
glFrontFace(GL_CCW);
glShadeModel(GL_SMOOTH);
glEnable(GL_CULL_FACE);
glDepthFunc(GL_LEQUAL);
glEnable(GL_DEPTH_TEST);
//glDepthMask(GL_TRUE);
//glEnable(GL_NORMALIZE);
//glEnable(GL_COLOR_MATERIAL);
//glEnable(GL_TEXTURE_2D);
glDisable(GL_STENCIL_TEST);
glDisable(GL_ALPHA_TEST);
glDisable(GL_SCISSOR_TEST);
{
GLfloat fSizes[2];
glGetFloatv(GL_SMOOTH_POINT_SIZE_RANGE, fSizes);
fprintf(stderr, %f %f\n, fSizes[0], fSizes[1]);
}
glClearColor(0.5f, 0.5f, 0.5f, 1.0f);
printf((e)GL engine initialized\n);
return(1);
}
int main(int argc, char *argv[])
{
/* perform graphics initialization here */
if (InitializeGraphics() == 0)
{
fprintf(stderr, failed to initialize uMfd graphics interace\n);
return(1);
}
/* start up the plugins */
if (uMfdInit(argc, argv, UMFD_CONTEXT_GLUT) == 0)
{
fprintf(stderr, failed to initialize uMfd plugin interface\n);
fprintf(stderr, failed to initialize uMfd plugin interface\n);
return(1);
}
/* main render loop if needed */
glutMainLoop();
uMfdFree(c);
/* return success */
return(0);
}
/code
/MainGlut.c
MainWayland.c
code
/*
* Copyright © 2011 Benjamin Franzke
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of the copyright holders not be used in advertising or
* publicity pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no representations
* about the suitability of this software for any purpose. It is provided as
* is without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF
Re: Weston framerate (Re: bare bones opengl weston client sample)
I will post code when I get to the hotel tonight. Basically, I simply ifdef'd in redraw() in simple-egl and branched into my draw routine. I will post both wl_client and glut front ends. Thank you for your help. Is there a place that describes any threading model there may be in iterate or flush that could cause a block? On Sep 10, 2012 6:49 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Fri, 7 Sep 2012 20:48:17 -0400 jegde jedge bubba...@gmail.com wrote: Sorry for the delay, my mail tool didn't link up this thread fro me. I am running w/ DRM not X11; running weston in an X client was not adequate for my test app. I start by obtaining a virtual terminal ;init 3 ; then weston-launch This way I eliminate any X11 variables. You can see egl loading the dri driver when it starts up. If there is a better way please let me know. Should be fine, I think. I run the the application with glut and weston using the same MESA stack that I compiled for weston. So, the only real difference is between glut/simple-egl and gnome(X11)/weston My CPU usage is: weston - ~20+ fps - 3% glut(X11) - 60 fps - 17% - (60 is a hard limit for glut) tells me there is more to be had. This application renders ~100 256x256 rgb textures on a moving map display. I don't understand the wayland frame listener callback and how the wl_iterate works to drive redraw in simple-egl. wl_display_iterate(), depending on the arguments, will receive and/or send Wayland protocol messages. When it is receiving, it will dispatch calls to your handlers, the frame listener callback for instance. Usually the frame listener callback sets a flag, that the app can repaint now. When wl_display_iterate() returns, you repaint, and the protocol messages (posting a buffer) are sent on the next call to wl_display_iterate(). simple-egl takes a shortcut and does not use a flag. It plays with the frame callback object pointer to avoid posting buffers too often (to avoid stalling in libEGL). The redraw function actually is the frame callback to be called, so it is rendering and posting buffers as fast as reasonable. More complex applications could use a better structure than this. So, I am hoping I am just using it wrong. I hope so too. Can you publish your code? I was hoping to do something similar to glutPostRedisplay() in a mouse drag event. This way I can start panning my textured tiles for a good test. Yeah, you should add a flag for that, and check it when wl_display_iterate() returns. The toytoolkit has the deferred_list for it, called in display_run() where the main loop is, see window.c. You don't see wl_display_iterate() explicitly in the display_run() loop. wl_display_flush() calls wl_display_iterate() to send all pending messages. The epoll has the Wayland fd in its list, and will end up calling handle_display_data() when there are wayland messages to be received. That will then call wl_display_iterate() to receive and dispatch. The toytoolkit main loop is worth looking at. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston framerate (Re: bare bones opengl weston client sample)
Sorry for the delay, my mail tool didn't link up this thread fro me. I am running w/ DRM not X11; running weston in an X client was not adequate for my test app. I start by obtaining a virtual terminal ;init 3 ; then weston-launch This way I eliminate any X11 variables. You can see egl loading the dri driver when it starts up. If there is a better way please let me know. I run the the application with glut and weston using the same MESA stack that I compiled for weston. So, the only real difference is between glut/simple-egl and gnome(X11)/weston My CPU usage is: weston - ~20+ fps - 3% glut(X11) - 60 fps - 17% - (60 is a hard limit for glut) tells me there is more to be had. This application renders ~100 256x256 rgb textures on a moving map display. I don't understand the wayland frame listener callback and how the wl_iterate works to drive redraw in simple-egl. So, I am hoping I am just using it wrong. I was hoping to do something similar to glutPostRedisplay() in a mouse drag event. This way I can start panning my textured tiles for a good test. On Fri, Sep 7, 2012 at 2:16 AM, Pekka Paalanen ppaala...@gmail.com wrote: On Thu, 6 Sep 2012 11:25:20 -0400 jegde jedge bubba...@gmail.com wrote: Thank you so much, that did the trick! Next Question :) On the same code, on the same hardware... I am getting the glut 60 fps limit when running my app using the glut front end via gnome and X. I am getting ~24 fps using the simple-egl front end on top of wayland. I also noticed the display using wayland likes to hover around 20 fps. Is there some kind of throttle built into the frame rate for the redraw callback? Hi, could you remind us, are you running Weston with the X11 or DRM backend? If you use the X11 backend, sloppy framerates are expected. X has no method of telling the X application (weston) that the image it posted has now hit the screen. Therefore the X11 backend fakes it by using a timer to blindly to trigger this image hit the screen callback. Obviously that is very flakey and inaccurate, but cannot really do any better. However, if you are on DRM backend, it is worth investigating. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Thank you so much, that did the trick! Next Question :) On the same code, on the same hardware... I am getting the glut 60 fps limit when running my app using the glut front end via gnome and X. I am getting ~24 fps using the simple-egl front end on top of wayland. I also noticed the display using wayland likes to hover around 20 fps. Is there some kind of throttle built into the frame rate for the redraw callback? Thank you. On Wed, Sep 5, 2012 at 8:59 PM, Kristian Høgsberg k...@bitplanet.net wrote: On Wed, Sep 5, 2012 at 8:11 PM, jegde jedge bubba...@gmail.com wrote: Thanks, I tried that route. it is a gles2 not gles or opengl example; and that will not work with the fixed function pipeline functions like glPushMatrix et.al. Sure, it's a gles2 example, but it shows you how to get a minimal egl/gles2 client working under wayland. I figured you'd want to replace the gles2 code with your own code anyway, and yes, it is just a matter of using EGL_OPENGL_API, removing the context attributes and linking to libGL. Kristian I went with the gears example since it binds the OPENGL API but it uses the window/toytoolkit/libshared stuff with cairo and I don't have enough insight to what is needed and what isnt. Is it as simple as replacing line 131: ret = eglBindAPI(EGL_OPENGL_ES_API); with EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? Thank you. I'll try in the morning. On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg k...@bitplanet.net wrote: Right under your nose: http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c Kristian On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge bubba...@gmail.com wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
I forgot to mention. its on 945GME glut 60 fps uses 17%cpu wayland 24 fps uses 3% cpu I am hoping for an apples to apples. ! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
bare bones opengl weston client sample
Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: bare bones opengl weston client sample
Thanks, I tried that route. it is a gles2 not gles or opengl example; and that will not work with the fixed function pipeline functions like glPushMatrix et.al. I went with the gears example since it binds the OPENGL API but it uses the window/toytoolkit/libshared stuff with cairo and I don't have enough insight to what is needed and what isnt. Is it as simple as replacing line 131: ret = eglBindAPI(EGL_OPENGL_ES_API); with EGL_OPENGL_API and linking against GL/libGL instead of GLES2/libGLES2 ? Thank you. I'll try in the morning. On Wed, Sep 5, 2012 at 4:51 PM, Kristian Høgsberg k...@bitplanet.net wrote: Right under your nose: http://cgit.freedesktop.org/wayland/weston/tree/clients/simple-egl.c Kristian On Wed, Sep 5, 2012 at 4:29 PM, jegde jedge bubba...@gmail.com wrote: Is there a bare bones open gl example that implemnts the bare minimum needed to get a wayland surface and begin drawing using openGL? I'm having a hell of a time porting my GLES1 application to run as a wayland/weston client. This application has run on psp, iPone, glut, and android. Since It is gles I used the weston gears client application as a template. Basically, I just inserted the hooks to call my applications draw routines using the egl config already provided. I have tiled textured maps working, but I am having some hoaky results with the first texture that it loaded. I would like to eliminate cairo pixman, libtoytoolkit, libshare.a as variables. I just dont see an example to do openGL with only wl_xxx() calls. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
wayland hosted VM
I have noticed that running a GLES application through the xserver is considerably slower Basically, I go from 60+ to 20 fps. This raises a smiler concern wrt running VM's with a wayland/egl stack. I imagine a VM display will act similar to the xserver architecturally. If that is so, is it envisioned that VMs will be able to utilize the GPU (i.e., write shaders) when running on wayland? Has there been discussion on this? If, so, please point me in the right direction. Respectfully, ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
xwayland crash
Just brought up wayland, weston, qt5, and xwayland on intel 945. I can reproduce an Xorg crash everytime. bring up # weston-launch -- --xserver run any number of X clients mouse over an X client and start scrolling the mouse wheel. This will most likely crash Xorg and all the X clients. Sometimes it brings down weston All other mouse and keyboard events that I tried could NOT bring it down, just the mouse wheel. If you 'wheel slowly' all is well. Let me know if anyone would like me to help troubleshoot. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Q: xwayland overt Qt-compositor?
Thanks everybody. I ran into a few blocks trying to build qtwayland/src/plugins/platform/wayland I have to keep two separate libxkbcommon's around one for weston and one for qt5. weston will not compile against the sha:3fbc277... version qt says they require I don't know how to make 'qmake' on qtwayland git: qtwayland in the qt5 alpha tarball fails with: qwaylandbuffer.h:66: error: ‘wl_buffer_damage’ was not declared in this scope qwaylandbuffer.h:68: error: ‘wl_buffer_damage’ was not declared in this scope I cannot find wl_buffer_damage in the wayland source I tried both master and the qt required sha:c855d6eec... ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Q: xwayland overt Qt-compositor?
Please forgive the 'user' post in a devel list. I am porting a fundamentally Qt system but still need some X backward compatability? I am unclear of the Qt/X/Weston/Wayland interoperability. Does the weston compositor work with Qt5 apps? Can the Qt5-compositor run the Weston apps? Will the Qt compositor host the xwayland server? Am I asking the right questions? Please help me understand the vision as it relates to future Qt and past X both running on Wayland. Respectfully ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Q: xwayland overt Qt-compositor?
On Tue, Aug 21, 2012 at 9:28 AM, Jørgen Lind jorgen.l...@nokia.com wrote: Hi, On Tue, Aug 21, 2012 at 09:15:54AM -0400, ext jegde jedge wrote: Please forgive the 'user' post in a devel list. Does the weston compositor work with Qt5 apps? Yes Can the Qt5-compositor run the Weston apps? Yes Am I asking the right questions? I don't know, are you getting the answers you want :) yes :) Thank you so much. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston doesn't work with gl enabled cairo on radeon
On Fri, Aug 10, 2012 at 9:54 PM, Nerdopolis bluescreen_aven...@verizon.net wrote: darxus@... writes: Is this a bug in weston or cairo? IIt's a bug in Mesa. Try reverting mesa to commit 102617bc5206e459bb1743d2d72341dbfe77bc58 That's what I had to do. Fixed my issue here http://lists.freedesktop.org/archives/wayland-devel/2012-August/004843.html on i915 thank you. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: weston 0.95 on 945GME using i915 drm
SOLVED here: http://lists.freedesktop.org/archives/wayland-devel/2012-August/004854.html ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
weston 0.95 on 945GME using i915 drm
Please point me in the right direction to get weston up from the
virtual terminal.
I have 0.95 currently working under X, but not DRM or wayland from a
virtual tty.
( I am new, how do you refer to the vtty wayland EGL platform? )
( I have mesa master currently running mesa egl demos from the tty )
I have installed and tested the following configuration:
ENVIRONMENT
export WLD=/home/bcpl/install # change this to another location if you prefer
export LD_LIBRARY_PATH=$WLD/lib
export
PKG_CONFIG_PATH=$WLD/lib/pkgconfig/:$WLD/share/pkgconfig/:/usr/lib/pkgconfig/:/usr/share/pkgconfig/
export ACLOCAL=aclocal -I $WLD/share/aclocal
export MESA_DEBUG=1
export EGL_LOG_LEVEL=debug
export EGL_DRIVERS_PATH=$WLD/lib
#export EGL_PLATFORM=drm
#export EGL_PLATFORM=fbdev
#export EGL_PLATFORM=wayland
export LIBGL_DEBUG=verbose
export WAYLAND_DEBUG=1
export XDG_RUNTIME_DIR=/home/bcpl/wayland/xdg
#export XDG_RUNTIME_DIR=/tmp/
#export CFLAGS=-g -I${WLD}/include -DEBUG -DHAVE_PIPE_LOADER_DRM
#export CXXFLAGS=-g -I${WLD}/include -DEBUG -DHAVE_PIPE_LOADER_DRM
export CFLAGS=-g -I${WLD}/include -DEBUG
export CXXFLAGS=-g -I${WLD}/include -DEBUG
export LDLAGS=-g -ldl
#sudo groupadd weston-launch
#sudo usermod -a -G weston-launch $USER
## Log all the way out (of X, etc.)
#sudo chown root weston-launch
#sudo chmod +s weston-launch
MESA
$ ./configure --prefix=/home/bcpl/install --enable-egl --enable-gles1
--enable-gles2 --with-egl-platforms=drm,wayland,x11,fbdev
--enable-shared-glapi --with-dri-drivers=i915,i965,r200,swrast
--enable-gbm --with-gallium-drivers=i915,swrast,nouveau
--enable-gallium-egl
Note:
I could not get eglgears_screen working without the gallium drivers
AND I could not get gallium drm to compile without the
HAVE_PIPE_LOADER_DRM symbol AND I could not get that symbol configured
without enabling the nouveau driver.
here is the EGL debug info:
Note: it selects gallium for the best driver:
bcpl@localhost ~]$ source ~/wayland/wld.rc
[bcpl@localhost ~]$ ./mesa-demos-8.0.1/src/egl/opengles1/torus_screen
libEGL debug: Native platform type: drm (build-time configuration)
libEGL debug: EGL search path is
/home/bcpl/install/lib:/home/bcpl/install/lib/egl
libEGL debug: added /home/bcpl/install/lib/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: added egl_glx to module array
libEGL debug: dlopen(/home/bcpl/install/lib/egl/egl_gallium.so)
libEGL info: use DRM for display (nil)
libEGL debug: the best driver is Gallium
EGL_VERSION = 1.4 (Gallium)
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
Found 1 modes:
0: 1024 x 768
Will use screen size: 1024 x 768
979 frames in 5.0 seconds = 195.761 FPS
(FBDEV also works as root)
WAYLAND/WESTON
I could only get wayland/weston 0.95 to compile against the mesa
master branch. I could not get 0.85 to compile against
Mesa-8.0.(0,1,2,3,4)
Running weston with an X server up and DISPLAY set works!
When I switch to the terminal and run ~/install/bin/weston the machine
hangs until I ssh in and kill weston.
this time DRI2 is selected before respawning and setting EGL_PLATFORM
to wayland.
I will be focusing here unless directed otherwise:
[11:45:07.736] libwayland: disconnect from client 0x856c1d0
wl_drm@11: error 2: invalid name
Here is the entire weston output:
[bcpl@localhost bin]$ cat weston.log
Date: 2012-08-10 UTC
[11:45:05.191] weston 0.95.0
http://wayland.freedesktop.org/
Bug reports to:
https://bugs.freedesktop.org/enter_bug.cgi?product=weston
Build: 0.95.0-76-g3d89049-dirty config-parser: Handle
lines that don't end in
(2012-08-03 21:56:41 -0400)
[11:45:05.192] OS: Linux, 2.6.32-220.el6.i686, #1 SMP Wed Nov 9
08:02:18 EST 2011, i686
[11:45:05.192] Loading module '/home/bcpl/install/lib/weston/drm-backend.so'
[11:45:05.193] initializing drm backend
[11:45:05.194] using /dev/dri/card0
libGL: Can't open configuration file /etc/drirc: No such file or directory.
libEGL debug: Native platform type: drm (autodetected)
libEGL debug: EGL search path is
/home/bcpl/install/lib:/home/bcpl/install/lib/egl
libEGL debug: added /home/bcpl/install/lib/egl/egl_gallium.so to module array
libEGL debug: added egl_dri2 to module array
libEGL debug: added egl_glx to module array
libEGL debug: dlopen(/home/bcpl/install/lib/egl/egl_gallium.so)
libEGL info: use DRM for display 0x82c1e18
libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in
eglInitialize(no usable display)
libEGL debug: the best driver is DRI2
libGL: Can't open configuration file /etc/drirc: No such file or directory.
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
[11:45:05.218] EGL version: 1.4 (DRI2)
[11:45:05.218] EGL vendor: Mesa Project
[11:45:05.218] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2
[11:45:05.218] EGL extensions: EGL_MESA_drm_image EGL_WL_bind_wayland_display
EGL_KHR_image_base
Re: weston 0.95 on 945GME using i915 drm
Thank you for your help. It looks like I have a dri/mesa issue to resolve before I can run weston... Is there a resource that shows how to get mesa egl/dri/drm working on i915? I rebuilt (make clean, make, make install) mesa, then pixman, then cairo, then weston. When I recompile mesa with --disable-gallium-egl, I now fail where gallium works: [code]code [bcpl@localhost ~]$ source wayland/wld.rc [bcpl@localhost ~]$ ./mesa-demos-8.0.1/src/egl/opengles1/torus_screen libEGL debug: Native platform type: drm (build-time configuration) libEGL debug: EGL search path is /home/bcpl/install/lib:/home/bcpl/install/lib/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: the best driver is DRI2 EGL_VERSION = 1.4 (DRI2) libEGL debug: attribute 0x3033 has an invalid value 0x8 libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in eglChooseConfig EGLUT: failed to choose a config /code[/code] When I run with weston-launch i get: failed to get cairo egl argb device failed to create display: Invalid argument [code]code [bcpl@localhost bin]$ source ~/wayland/wld.rc [bcpl@localhost bin]$ ./weston-launch Date: 2012-08-10 UTC [14:41:13.327] weston 0.95.0 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=weston Build: 0.95.0-76-g3d89049-dirty config-parser: Handle lines that don't end in (2012-08-03 21:56:41 -0400) [14:41:13.327] OS: Linux, 2.6.32-220.el6.i686, #1 SMP Wed Nov 9 08:02:18 EST 2011, i686 [14:41:13.329] Loading module '/home/bcpl/install/lib/weston/drm-backend.so' [14:41:13.330] initializing drm backend [14:41:13.337] using /dev/dri/card0 libEGL debug: Native platform type: drm (autodetected) libEGL debug: EGL search path is /home/bcpl/install/lib:/home/bcpl/install/lib/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: the best driver is DRI2 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable [14:41:13.361] EGL version: 1.4 (DRI2) [14:41:13.361] EGL vendor: Mesa Project [14:41:13.361] EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 [14:41:13.361] EGL extensions: EGL_MESA_drm_image EGL_WL_bind_wayland_display EGL_KHR_image_base EGL_KHR_gl_renderbuffer_image EGL_KHR_surfaceless_context [14:41:13.361] GL version: OpenGL ES 2.0 Mesa 8.1-devel (git-04a11b5) [14:41:13.361] GLSL version: OpenGL ES GLSL ES 1.0.16 [14:41:13.361] GL vendor: VMware, Inc. [14:41:13.361] GL renderer: Gallium 0.4 on i915 (chipset: 945GME) [14:41:13.361] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_EXT_read_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer [14:41:13.413] failed to get plane resources: Invalid argument [14:41:13.413] Output LVDS1, (connector 5, crtc 4) mode 1024x768@60.0, preferred, current mode 1024x768@60.0 [14:41:13.833] input device Power Button, /dev/input/event2 is a keyboard [14:41:13.836] input device Sleep Button, /dev/input/event0 is a keyboard [14:41:13.839] input device Power Button, /dev/input/event1 is a keyboard [14:41:13.845] input device Interlink Electronics, Inc. FSR 4ZUSB, /dev/input/event8 is a pointer [14:41:13.848] input device DRS Inc. DRS Inc. Keyboard, /dev/input/event9 is a keyboard [14:41:13.851] input device Hampshire Company TSHARC Analog Resistive, /dev/input/event5 is a pointer [14:41:13.854] input device Dell Dell USB Optical Mouse, /dev/input/event11 is a pointer [14:41:13.862] input device Dell Dell Wired Multimedia Keyboard, /dev/input/event6 is a keyboard [14:41:13.865] input device Dell Dell Wired Multimedia Keyboard, /dev/input/event7 is a pointer [14:41:13.865] input device Dell Dell Wired Multimedia Keyboard, /dev/input/event7 is a keyboard [14:41:13.868] input device AT Translated Set 2 keyboard, /dev/input/event4 is a keyboard [14:41:13.871] input device Macintosh mouse button emulation, /dev/input/event3 is a pointer [14:41:13.871] Loading module '/home/bcpl/install/lib/weston/desktop-shell.so' [14:41:13.879] libwayland: using socket /home/bcpl/wayland/xdg/wayland-0 libEGL debug: Native platform type: wayland (autodetected) libEGL debug: EGL search path is /home/bcpl/install/lib:/home/bcpl/install/lib/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: pci
Re: weston 0.95 on 945GME using i915 drm
Thanks again. I Really appreciate the help. I wiped everything, started from scratch, and followed the build instructions at http://wayland.freedesktop.org/building.html verbatim. With this mesa build I cannot get any mesa-demo-8.0.1/src/egl/opengl/demo_screen example to run from the tty console. The ~/src/egl/opengl/demo_x11 examples do work linking these specific mesa libs. Here are the results from the weston-launch: [bcpl@localhost bin]$ cat weston.log Date: 2012-08-10 UTC [17:39:58.209] weston 0.95.0 http://wayland.freedesktop.org/ Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=weston Build: [17:39:58.209] OS: Linux, 2.6.32-220.el6.i686, #1 SMP Wed Nov 9 08:02:18 EST 2011, i686 [17:39:58.211] Loading module '/home/bcpl/install/lib/weston/drm-backend.so' [17:39:58.211] initializing drm backend [17:39:58.218] using /dev/dri/card0 libEGL debug: Native platform type: drm (autodetected) libEGL debug: EGL search path is /home/bcpl/install/lib:/home/bcpl/install/lib/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: the best driver is DRI2 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable [17:39:58.238] EGL version: 1.4 (DRI2) [17:39:58.238] EGL vendor: Mesa Project [17:39:58.238] EGL client APIs: OpenGL OpenGL_ES2 [17:39:58.238] EGL extensions: EGL_MESA_drm_image EGL_WL_bind_wayland_display EGL_KHR_image_base EGL_KHR_gl_renderbuffer_image EGL_KHR_surfaceless_context [17:39:58.238] GL version: OpenGL ES 2.0 Mesa 8.1-devel (git-f7af4be) [17:39:58.238] GLSL version: OpenGL ES GLSL ES 1.0.16 [17:39:58.238] GL vendor: Intel Open Source Technology Center [17:39:58.238] GL renderer: Mesa DRI Intel(R) 945GME x86/MMX/SSE2 [17:39:58.238] GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_stencil8 GL_OES_texture_3D GL_OES_texture_npot GL_OES_EGL_image GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_EXT_read_format_bgra GL_NV_fbo_color_attachments GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer [17:39:58.292] failed to get plane resources: Invalid argument [17:39:58.292] kms connector 5, crtc 4 mode 1024x768@60.0, preferred, current mode 1024x768@60.0 [17:39:58.736] Loading module '/home/bcpl/install/lib/weston/desktop-shell.so' [17:39:58.743] libwayland: using socket /home/bcpl/wayland/xdg/wayland-0 libEGL debug: Native platform type: wayland (autodetected) libEGL debug: EGL search path is /home/bcpl/install/lib:/home/bcpl/install/lib/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: pci id for 5: 8086:27ae, driver i915 libEGL debug: DRI2: dlopen(/home/bcpl/install/lib/dri/i915_dri.so) libEGL debug: DRI2: found extension `DRI_Core' libEGL info: DRI2: found extension DRI_Core version 1 libEGL debug: DRI2: found extension `DRI_DRI2' libEGL info: DRI2: found extension DRI_DRI2 version 3 libEGL debug: DRI2: found extension `DRI_TexBuffer' libEGL info: DRI2: found extension DRI_TexBuffer version 2 libEGL debug: DRI2: found extension `DRI2_Flush' libEGL info: DRI2: found extension DRI2_Flush version 3 libEGL debug: DRI2: found extension `DRI_IMAGE' libEGL info: DRI2: found extension DRI_IMAGE version 5 libEGL debug: DRI2: found extension `DRI_CONFIG_QUERY' libEGL debug: the best driver is DRI2 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn compression/decompression unavailable failed to get cairo egl argb device failed to create display: Invalid argument libEGL debug: Display 0x82dee60 is destroyed with resources [17:39:58.798] libwayland: disconnect from client 0x8c946a0 [17:39:58.799] weston-desktop-shell died, respawning... libEGL debug: Native platform type: wayland (autodetected) libEGL debug: EGL search path is /home/bcpl/install/lib:/home/bcpl/install/lib/egl libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: pci id for 5: 8086:27ae, driver i915 libEGL debug: DRI2: dlopen(/home/bcpl/install/lib/dri/i915_dri.so) libEGL debug: DRI2: found extension `DRI_Core' libEGL info: DRI2: found extension DRI_Core version 1 libEGL debug: DRI2: found extension `DRI_DRI2' libEGL info: DRI2: found extension DRI_DRI2 version 3 libEGL debug: DRI2: found extension `DRI_TexBuffer' libEGL info: DRI2: found extension DRI_TexBuffer version 2 libEGL debug: DRI2: found extension `DRI2_Flush' libEGL info: DRI2: found extension DRI2_Flush version 3 libEGL debug: DRI2: found extension
Re: weston 0.95 on 945GME using i915 drm
Looks like it is failing in: ~/mesa/egl/main/eglapi.c::eglCreatePBufferSurface() ~/cairo/src/cairo_egl_context.c:: cairo_egl_device_create() ~/weston/clients/window.c::init_egl() ~/weston/clients/window.c::display_create() This means that all the boilerplate egl initialization has completed successfully. I could not yet track what driver/lib has drv-API.CreatePBufferSurface() Don't know what to try next. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[codezero-devel] v0.5.0 equivalent to replace build.py -C
The codezero.git devel repo provides an intuitive means (kernel menu configure) to define the number of containers and there corresponding attributes. How is this done in version 0.5.0? this tutorial does not seem to apply to the new release: http://l4dev.org/getting_started_quick Any help is appreciated. ___ codezero-devel mailing list codezero-devel@lists.l4dev.org http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
Re: [codezero-devel] ubuntu/python/bsddb
SOLVED Problem 1: ubuntu python compiled with _bsddb missing. Problem 2: python will not compile with latest version of berkeley db Problem 3: codezero db files are built usinig version 4.6 of berkeley bsddb which is known buggy and explicitly shunned by python. Problem 4: changing python on ubuntu oneiric really honks the distro Fixed my problem with the following steps. Hope this helps somebody. 1) Download and install python versions 4.5 and 4.6 from: http://download.oracle.com/berkeley-db/db-4.5.20.tar.gz http://download.oracle.com/berkeley-db/db-4.6.21.tar.gz use the default configure options as it installs in a specific /usr/local/BerkeleyDB.4.5 directory that Python expects This order is required #build python supported berkeley db cd rm -Rf db-* tar -xzf Downloads/db-4.5.20.tar.gz cd db-4.5.20/build ../dist/configure sudo make install # build local copy of python linked against berkeley db 4.5 cd rm -Rf Python* tar -xjf Python-2.7.2.tar.bz2 cd Python-2.7.2 ./configure make # do not make install #install berkeley 4.6 so we can recover the codezero configuration files cd tar -xzf Downloads/db-4.6.21.tar.gz cd db-4.6.21/build ../dist/configure sudo make install # recover the configuration files cd rm -Rf codezero* tar -xjf Downloads/codezero-toolkit-v0.5.0-full.tar.bz2 cd codezero-toolkit-v0.5.0-full/codezero-toolkit/prebuilt mv configuration configuration4.6 /usr/local/BerkeleyDB.4.6/bin/db_dump configuration4.5 | /usr/local/BerkeleyDB.4.5/bin/db_load configuration4.5 cp configuration4.5 configuration # now run the build.py using the local copy of python export PATH=~/Python-2.7.2:$PATH which python python -V cd cd codezero-toolkit-v0.5.0-full/codezero-toolkit/prebuilt python build.py ___ codezero-devel mailing list codezero-devel@lists.l4dev.org http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
Re: [codezero-devel] ubuntu/python/bsddb
I forgot to mention. I also tried these packages: sudo apt-get install libdb-dev sudo apt-get install python-bsddb3 ___ codezero-devel mailing list codezero-devel@lists.l4dev.org http://lists.l4dev.org/mailman/listinfo/codezero-devel_lists.l4dev.org
