Re: [waffle] [PATCH v2 2/4] gl_basic: print a message if gl_basic is successful
I committed this patch to master. On 08/13/2012 05:11 PM, Jordan Justen wrote: Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- examples/gl_basic.c |1 + 1 file changed, 1 insertion(+) diff --git a/examples/gl_basic.c b/examples/gl_basic.c index 800756a..ea9243d 100644 --- a/examples/gl_basic.c +++ b/examples/gl_basic.c @@ -434,5 +434,6 @@ main(int argc, char **argv) cocoa_finish(); #endif +printf(gl_basic: run was successful\n); return EXIT_SUCCESS; } ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] waffle-1.0.0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Waffle 1.0.0 - 22 Aug 2012
==
Waffle 1.0.0 is now available. Downloads and documentation are available at
http://people.freedesktop.org/~chadversary/waffle/releases.html#1.0.0
Waffle is a cross-platform library that allows one to defer selection of GL
API and of window system until runtime. For example, on Linux, Waffle enables
an application to select X11/EGL with an OpenGL 3.3 core profile, Wayland with
OpenGL ES2, and other window system / API combinations.
Notes for Piglit/Waffle Users
- -
If you configure Piglit to use Waffle, please note that Piglit now requires
waffle-1.0.
API/ABI Stability
- -
Until version 1.0, Waffle's API was rapidly evolving and unstable. Version
1.0 marks a stability milestone: all future 1.x releases will be API and ABI
compatibile with previous 1.x releases.
(Note that waffle-1.0 is not backwards compatible with waffle-0.3).
New Features since 0.3
- --
- - Ability to obtain the underlying native objects of each waffle object with
the waffle_${object}_get_native methods. This feature allows users to
implement interactions with the native objects, such as keyboard input, that
lie outside Waffle's scope.
Acknowledgements
-
Contributors to this release:
Ben Widawski b...@bwidawsk.net
Chad Versace chad.vers...@linux.intel.com
Jordan Justen jordan.l.jus...@intel.com
Pauli Nieminen pauli.niemi...@linux.intel.com
Testers:
Kenneth Graunke kenn...@whitecape.org
Dylan Baker baker.dyla...@gmail.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJQNsYCAAoJEAIvNt057x8iBuwQAIsGL5cLEO7pQVeA5vjPKkIw
hpCG2sAHt0oyxKcccTVRzW+nZa0w+vQmUX3hovLTmcChxhW4OaL/Riew8TTkFeCG
4/m3R3u5BS38K3WX4MtKqW1/Nq8rV+Wnn/8azZ5rIX4tpQjzAOj4qJm0koBodUol
AuW92HmaJgOeFq2dErPxumCQejVXb1ExOgcSi6JIfbzztmfrmhnTuE93md3naj5P
q+//fE0KHMu7aE33byAMi0Gwjq4sQSE1SYAt9HHLtKFJnZIUH195UQ+KYzoQnd+C
383Ba69G9VisCjRF7Al/uoC0bolzqxFgwBsg1aGaP380bkqh3jPurkDSYsAsrxos
ZvOuQwjdHxbwhff/RQkUTnvPkJdUdOFW0a/vYG6H0zAH8rhD7dQOGFdIGGvfKOrt
D2v2qJWGbtT4F2YoYUPjDKdhIZkOqASIJ+6ZLkZUvNQiQ0T67DdWp0BGwPd5kDzW
7P4tL3XQGJvgOWMGsOBY5k4jIYiXRoIkJFTuqW8xXbXsGCnPmN60V93M6TG8mlhB
W8HdyN5vEJUzvyPOWEGR4lMT4KBmhy+se+5F+rskw7nwEdkqhhek3wVpLVpfX9da
I+QJ9d/k0VNws22hmmtS13I08GRjhyFC7IdzVadMWQeEiK/jvWQmcPIjQjyXjOla
isk7eMdZxrdRix2Z+fdg
=B38x
-END PGP SIGNATURE-
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] waffle-1.0.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Waffle 1.0.1 - 29 Aug 2012 == Waffle 1.0.1 is a bugfix release. It fixes bugs discovered since the 1.0.0 release. Downloads and documentation are available at http://people.freedesktop.org/~chadversary/waffle/releases.html#1.0.1 Changes - --- The full set changes can be viewed with `git log waffle-1.0.0..waffle-1.0.1`. Chad Versace (4): include: Fix #include's in waffle_glx.h api: Fix return values waffle: Fix waffle_*_get_native functions waffle: Bump version to 1.0.1 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQPv+fAAoJEAIvNt057x8iO2AP/jFkU0nM8NbpG97jAO7lBHi6 +i/hcgO8HM7yM1GxomqW2N2eh5v+JroTuhjaD8+oHDO3tdQh6+8arav1Dn7dWck/ WEKsQJee2wH38lqnIoZ/UuS35UjFTiVQhj2owaCrCUwx7bZEEqAPBR3BkpD+EsT/ fEjnoGT9wOok4n6Cqyh2bLU6ExQGfVmXf1KnWB8wq2cIIeiTRDlLj7YsfAf1J3Pq wWbkXQeIxpEXzwHmfpeaRVUSq0YDVmM9Puc1adZdFuCngW366os4pUh+YyzjHQVi 30jiAwqsFU5ZyNIT2jwx58RStgWcqDa5ZtyxS6Rmgr3r7EHcmdxmHGvEunujRe0S FPveItk1SkcvZiEcahFAZ6afpHiaHm4d5ORLLqNLqRsoxxgUW7I/XAhM73lj44mS BwfeSgzEFvdRYbBtECWMFS4Hr7IfdXYaXQKEjnsEpSH4Xim+vYQMfYl2plXSd4hM wivrIFMjRh1vMHGv9DuFSFqsCwdfpmAjyKCI4vF7AchYq6vbjMjaBrj2Nf6xbHs4 UhmzaIL+e66eo3unlO1frW13Slr+i2cvDKikKPZBMBAbJY4aRIPRMWnZJFHrXkhP YqsHDHiHe7fkQoo3WaWp2hgrrU7yN+BSpV6R0bfVQYSugeOsmezLddu0m8f2MHt5 dSk6CJ6vguRTe3gtAY8o =I649 -END PGP SIGNATURE- ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] Enabling Waffle library for Android.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for incorporating the requested changes. I just commited the patch to master. I made a few cleanups to the patch, which I noted in the commit message. The code is nearly identical to your original patch, except that I had to rename some symbols to avoid namespace conflicts with the Android platform. On 08/20/2012 04:54 AM, Juha-Pekka Heikkilä wrote: Another week, another version for Android patch for Waffle. Again in the attachment. I did do some restructuring of my code to try to get the multiple window system working for Android but alas it seems this was useless work for now. Display now contain pointer to reach control over SurfaceComposerClient which is one per process type object, trying to initialize this for second time in one process will segfault the calling process. Apparently this has been so since Gingerbread, at least according to some googling I did. Window has pointer for SurfaceControl, creating many windowses would create many SurfaceControl objects allowing them to be independent from each other. Alas it seems for one SurfaceComposerClient one can only create single SurfaceControl object, creating second did make everything unstable. After creating second SurfaceControl accessing either SurfaceControl will segfault or freeze inside calling method. Once I notice this I tried it with simple piece of code which just create composer client and two surface controls to get the same behaviour as with when doing this with Waffle thus unless there is something I did totally miss it seems one process can only have one surface in Android for now. There is the video player which has the special secondary layer where the video is playing and I did not yet see how does it do it but I suspect layer for video is flagged to be special. With the surfaces I also found behaviour which was not very nice. After I destroy the surface and clean everything related to it to create a new surface I get same errors as if I was creating second surface with the first one still there giving me a segfault. To get the new surface there is a need for a new composer client which again is one per process. It's unfortunate that the Android framework behaves badly. I guess we'll just have to live those bugs until someone fixes them upstream. The patch will compile for JB by default. If one is compiling against ICS there is a need to add definition for 'BUILD_FOR_ICS'. This define will switch one include folder. By the way, in a follow-up patch I added some makefile magic to auto-detect if you're building for ICS or JB. It's no longer necessary to manually add CFLAGS for ICS. Thanks, Chad -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQPwHcAAoJEAIvNt057x8i9N8P/ioEIZ9lUqbqFNxSWdH61tkR jP0C/RMs11Sa8ToFYFew/dSpBjHvrh8arQRvwPM0sblCMMrAjyrnsHefD1uV9QQh YWOSucxKIE7jxOQDbsvZ1cFru1cWw6AeF/nDpwA0DV/PcD3Zx+9gifB5jccbsjrq 1zGS17SPzXMzxjs3jFe3qwOQyJa/ijKTzF0UOGOfxxkgoGLs9InTXEqrjl0dFzY/ hBwZAmBjy5QbO/rWr7YlsClVGHTARF08EVlVfEnU9o/JHvPSChhvfxkAai2iNOqt mTv8477hkhQW552EKwrYT78jkWl9N5hpLZzk7GHzXa29+Xwm+Q2nwHj5CHZ4joaS 1TEEeVJobjGD3BO/kCVk6ThrT4CtMJjLaT+7UKIn5tcHRnlcFIJ276+fhjc/WYXn h8KmqE347Jy4/y7nfAOIZ9xoFwzV7naF89nQ7LcufTNiHYPVBVw44WVUNjnXKZcl 5S5fqSRbgoj5UA/2FGcP2bi1fufIzCiicwaVgts5KmI9MkWhNbufciX22+QgO3J3 AKaGiukzfI2Jw+pSvzoz0DadPO92D0N8pZIw2TKjOpdp1odVJmgQRhneoJ7+siA3 2qtyZOa0Z5cromJ6ZbVg6o94RLpIvMdcUO9ILvz/qzzXljB0xl5ZJWQ2SQe3ZE5A H5upDpaTyYbZ9C+HTSAM =vU7/ -END PGP SIGNATURE- ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Waffle Mac Patches
[CC'ing waffle list] On 09/24/2012 09:50 PM, Jeff wrote: Hi Chad, Nice presentation on waffle at XDC! I was trying to build it on OSX and ran into some issues with the current git master. I made some patches that fix the build and attached them if you are interested in applying them (all 3 are attached) The first one fixes compile issues in the cgl backend with things like WAFFLE_UNSUPPORTED_ON_PLATFORM, being renamed to WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM. The second one fixes a compile issue I was having with including Cocoa.h in gl_basic.c with Cocoa.h somehow also including gl.h The third one adds Xcode projects to build a waffle static library and gl_basic (which links to it). Although the cmake build system works well, it's really nice having a full featured IDE and debugger available for use on OSX. I apologize if this is not the right channel, or if my patches are not good (I'm happy to tweak them according to your feedback). Hi Jeff, Thanks for the fixes, and apologies for letting the Mac support bitrotting. I committed all your patches to master. Next time I make global changes, such as renaming enums, I'll be sure to pull the dusty MacBook out of the closet and sanity check things before committing. Although the cmake build system works well, it's really nice having a full featured IDE and debugger available Agreed, it's nice to have full-featured IDE integration. I've never successfully used Xcode, though, so I'm trusting that your patch does the right thing :) -Chad ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH 4/4] core: Add unittests for boolean waffle_config attrs
This patch adds two unittests. Both tests pass.
wcore_config_attrs.sample_buffers_is_bad
wcore_config_attrs.accum_buffer_is_bad
Of the three boolean waffle_config attributes (WAFFLE_DOUBLE_BUFFERED,
WAFFLE_SAMPLE_BUFFERS, WAFFLE_ACCUM_BUFFER), only for
WAFFLE_DOUBLE_BUFFERED did a unittest exist that checked that an error was
thrown on bad values. This patch adds such a test for the other two.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/waffle/core/wcore_config_attrs_unittest.c | 30 +++
1 file changed, 30 insertions(+)
diff --git a/src/waffle/core/wcore_config_attrs_unittest.c
b/src/waffle/core/wcore_config_attrs_unittest.c
index f9cb866..66ec9cb 100644
--- a/src/waffle/core/wcore_config_attrs_unittest.c
+++ b/src/waffle/core/wcore_config_attrs_unittest.c
@@ -171,6 +171,34 @@ TEST(wcore_config_attrs, double_buffered_is_bad)
EXPECT_TRUE(strstr(wcore_error_get_info()-message, 0x31415926));
}
+TEST(wcore_config_attrs, sample_buffers_is_bad)
+{
+const int32_t attrib_list[] = {
+WAFFLE_CONTEXT_API, WAFFLE_CONTEXT_OPENGL,
+WAFFLE_SAMPLE_BUFFERS, 0x31415926,
+0,
+};
+
+ASSERT_TRUE(!wcore_config_attrs_parse(attrib_list, actual_attrs));
+EXPECT_TRUE(wcore_error_get_code() == WAFFLE_ERROR_BAD_ATTRIBUTE);
+EXPECT_TRUE(strstr(wcore_error_get_info()-message,
WAFFLE_SAMPLE_BUFFERS));
+EXPECT_TRUE(strstr(wcore_error_get_info()-message, 0x31415926));
+}
+
+TEST(wcore_config_attrs, accum_buffer_is_bad)
+{
+const int32_t attrib_list[] = {
+WAFFLE_CONTEXT_API, WAFFLE_CONTEXT_OPENGL,
+WAFFLE_ACCUM_BUFFER,0x31415926,
+0,
+};
+
+ASSERT_TRUE(!wcore_config_attrs_parse(attrib_list, actual_attrs));
+EXPECT_TRUE(wcore_error_get_code() == WAFFLE_ERROR_BAD_ATTRIBUTE);
+EXPECT_TRUE(strstr(wcore_error_get_info()-message,
WAFFLE_ACCUM_BUFFER));
+EXPECT_TRUE(strstr(wcore_error_get_info()-message, 0x31415926));
+}
+
TEST(wcore_config_attrs, core_profile_and_accum_buffer)
{
const int32_t attrib_list[] = {
@@ -296,6 +324,8 @@ testsuite_wcore_config_attrs(void)
TEST_RUN(wcore_config_attrs, double_buffered_is_true);
TEST_RUN(wcore_config_attrs, double_buffered_is_false);
TEST_RUN(wcore_config_attrs, double_buffered_is_bad);
+TEST_RUN(wcore_config_attrs, sample_buffers_is_bad);
+TEST_RUN(wcore_config_attrs, accum_buffer_is_bad);
TEST_RUN(wcore_config_attrs, core_profile_and_accum_buffer);
TEST_RUN(wcore_config_attrs, negative_red);
TEST_RUN(wcore_config_attrs, negative_green);
--
1.7.12.1
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] Trello board
For anyone interested, I've created a Trello board [1] for Waffle. It lists bugs and sundry tasks. There is also a link to the Trello board on Waffle's homepage. Ping me if you want write access. [1] https://trello.com/board/waffle/4f3d5a187864df3c3343c1a6 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Hi just found out about this project.
On 11/05/2012 03:17 AM, mortdeus wrote: Hi, I just found out about this, and it is perfect for my gocos2d project im working on. Nice. I wanted to know if you guys have looked into google's angle project at all and what your guys opinion is for using it for windows? I've never used ANGLE before, so I can't say. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Hi just found out about this project.
After thinking about it again this weekend, I can see how having a GLES1,GLES2 to D3D translation layer in Waffle would be useful, and it fits in nicely with a planned, future feature of Waffle. The new feature is a reproduction of GLEW's functionality---dispatching GL extension functions and their aliases--- but at the granularity of thread and context for all GL API's. This way, if one thread has a GLES2 context bound and another has a GL 3.2 compat context bound, each thread will be able to resolve and dispatch extension functions independently. I think ANGLE integration fits in nicely with this feature. However, I'm postponing the dispatch work until I finish the tasks I'm currently working on. You're re-implementing Waffle in Go! In the early stages in Waffle's development, I considered writing Waffle in Go, but eventually decided against it. I'm really interested in seeing what your re-implementation looks like. -Chad On 11/10/2012 10:39 AM, mortdeus wrote: Understood, well im going to go ahead and fork so I can make those extensions myself as part of my cross platform layer. Ill let you guys know if anything cool comes out of it. https://github.com/mortdeus/egles/tree/master/waffle On Thu, Nov 8, 2012 at 12:47 PM, Chad Versace chad.vers...@linux.intel.com mailto:chad.vers...@linux.intel.com wrote: I think those two subjects---translating GL to D3D and translating among GL api,s---is outside of the scope of Waffle. But my opinion may change as time unfolds. -Chad On 11/05/2012 11:59 AM, mortdeus wrote: You guys might want to check it out, it has the ability to translate gles2 to direct3d9, and for linux/bsd it can compile shaders to GLSL, ELSL. I assume that could be a great feature for waffle? On Mon, Nov 5, 2012 at 12:06 PM, Chad Versace chad.vers...@linux.intel.com mailto:chad.vers...@linux.intel.comwrote: On 11/05/2012 03:17 AM, mortdeus wrote: Hi, I just found out about this, and it is perfect for my gocos2d project im working on. Nice. I wanted to know if you guys have looked into google's angle project at all and what your guys opinion is for using it for windows? I've never used ANGLE before, so I can't say. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] waffle-1.2.1
Waffle 1.2.1 - 15 Nov 2012 == Waffle 1.2.1 is now available. This is a bugfix release that fixes critical bugs discovered since the 1.2.0 release. Download: http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.2.1/waffle-1.2.1.tar.xz sha256 sum: waffle-1.2.1.tar.xz 32fd13190ea3599241e2512fe1bcc40dde0a95d9d7ee0c52edc8de1bff5b1e15 Bugfixes * Fixes build breakage in Piglit, which uses -std=c90 on Linux. * Fix broken url in html documentation. Changes --- The full set of changes can be viewed with `git log waffle-1.2.0..waffle-1.2.1`. Chad Versace (3): doc/html: Fix fatal typo 'wafffle' in url include: #define restrict for C language c99 doc: Add waffle-1.2.1 release notes signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] android: Fold nearly all headers into waffle.h
Adrian,
I split this into two patches and committed it to the master and the 1.2 branch.
Like I said in IRC, apologies for the broken 1.2 release. Waffle is now at the
point where I can't decide alone that it's time to tag a release and publish
the tarball. For waffle-1.3, I'll pull you and Juha into the release process in
order to verify that everything works on Android before shipping.
I plan on tagging the 1.2 branch as waffle-1.2.2 on Wed 21 Nov.
-Chad
On 11/16/2012 05:35 AM, gro...@gmail.com wrote:
From: Adrian Marius Negreanu adrian.m.negre...@intel.com
also one c99-ism in wcore_config_attrs.c
Signed-off-by: Adrian Marius Negreanu adrian.m.negre...@intel.com
---
Android.mk | 13 +
src/waffle/core/wcore_config_attrs.c | 6 --
2 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/Android.mk b/Android.mk
index 09ef5c6..f7c42c5 100644
--- a/Android.mk
+++ b/Android.mk
@@ -82,22 +82,11 @@ LOCAL_GENERATED_SOURCES := \
$(LOCAL_PATH)/include/waffle_version.h
LOCAL_COPY_HEADERS := \
-include/waffle/waffle_attrib_list.h \
-include/waffle/waffle_config.h \
-include/waffle/waffle_context.h \
-include/waffle/waffle_display.h \
-include/waffle/waffle_dl.h \
-include/waffle/waffle_enum.h \
-include/waffle/waffle_error.h \
+include/waffle/waffle.h \
include/waffle/waffle_gbm.h \
-include/waffle/waffle_gl_misc.h \
include/waffle/waffle_glx.h \
-include/waffle/waffle.h \
-include/waffle/waffle_init.h \
-include/waffle/waffle_portability.h \
include/waffle/waffle_version.h \
include/waffle/waffle_wayland.h \
-include/waffle/waffle_window.h \
include/waffle/waffle_x11_egl.h \
LOCAL_COPY_HEADERS_TO := waffle-$(waffle_major_version)
diff --git a/src/waffle/core/wcore_config_attrs.c
b/src/waffle/core/wcore_config_attrs.c
index 1276e56..d100b97 100644
--- a/src/waffle/core/wcore_config_attrs.c
+++ b/src/waffle/core/wcore_config_attrs.c
@@ -41,7 +41,8 @@ check_keys(const int32_t attrib_list[])
if (attrib_list == NULL)
return true;
-for (int32_t i = 0; attrib_list[i]; i += 2) {
+int32_t i;
+for (i = 0; attrib_list[i]; i += 2) {
int32_t key = attrib_list[i];
switch (key) {
@@ -298,7 +299,8 @@ static bool
parse_misc(struct wcore_config_attrs *attrs,
const int32_t attrib_list[])
{
-for (int32_t i = 0; attrib_list[i]; i += 2) {
+int32_t i;
+for (i = 0; attrib_list[i]; i += 2) {
int32_t key = attrib_list[i + 0];
int32_t value = attrib_list[i + 1];
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] waffle-1.2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Waffle 1.2.2 - 27 Nov 2012 == Waffle 1.2.2 is now available. This is a bugfix release that fixes critical bugs discovered since the 1.2.1 release. Download: http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.2.2/waffle-1.2.2.tar.xz sha256 sum: 7e342c859b58d4e051b347ef3d7740ed2f3b6c506b93daec272724afe7dd1311 Bugfixes - * Fix creation of ES3 contexts on EGL. * Fix build on Android. Changes - --- The full set of changes can be viewed with `git log waffle-1.2.1..waffle-1.2.2`. Adrian Marius Negreanu (2): android: Fold nearly all headers into waffle.h android: Fix c99-ism in wcore_config_attrs.c Chad Versace (1): egl: Fix call to eglBindAPI for WAFFLE_OPENGL_ES3 Android.mk | 13 + src/waffle/core/wcore_config_attrs.c | 8 ++-- src/waffle/egl/wegl_context.c| 1 + 3 files changed, 8 insertions(+), 14 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQtWKgAAoJEAIvNt057x8ijvIQAIhGG4pp6nis6wlpbO4CtXmq bzl7htvukGgd8KC1Nn53p67EyNHq4snFhCyVb5/NAm1oP8g1MXUYYEsyY9wsC9HO EUcLa9OhpOYso8bh6yDI/QsGcKVE57iue8hrdYZ/VYbets/JcCaN+AD1MBvgEFFg ZckQoPEu47s5Khiw8jrTkdz7CpMD4Gqy8FQdJ8MAua+nnajhYqAJvy8B/fc2wBja IsaZmIglxjGE7qmgc5DcG7+RKWN1cm/X6DkVpE2reGJh0BcszC9rG+Ia3aLym0qX klTmjBxw7S3Rt5U0bTMigTJdIN/wl82r0apSEZb/vYQNdzMoPqAqC/emrgCR+KQW Rguj5bUXHTL82NYs7tIc+Ktppj/o9+8mz/6TsZNkQmwrp28pbTQqS6DAIGkGszBZ 7oeJ0zDduSn0r6XvEapScuwVNhsWsR64PVuXLQODo9BHy7T2S13W3Pz75xoZMkuJ z4ZuLdDPmUWyYC6Fj35N2E2B+bTXlwdAFEuA1SJMRIA8EhynOfLw5p1f9ThQMuo4 m9dBedol7uRrVeYHW7+gw+STHBO9En1+e7hezV1OAN4MZlhw4TzDhr0m8r6u0aGh hGeUlFeYIUEg7+Tk+oTL8s30UH0kF0HxHfdMTHEqF7NV39BxshjlYjvv6i89t3GX vMAJ1snnV+BbL8aqVwsJ =iaLk -END PGP SIGNATURE- ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] glx: make unsuccessful context creation not terminate the whole process
Marek, thanks. Until I figure out how waffle clients should register error handlers, this fix looks like a good workaround. I committed it to the master and 1.2 branch. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] Android: Fix surface setup segfault
On 02/18/2013 04:20 AM, Juha-Pekka Heikkila wrote: Seems like compiling with latest Android tree malloc/free did not work with structures in droid_surfaceflingerlink.cpp, some members in structures become strange causing segfault. Using new/delete fix this. Signed-off-by: Juha-Pekka Heikkila juha-pekka.heikk...@linux.intel.com --- src/waffle/android/droid_surfaceflingerlink.cpp | 18 -- 1 files changed, 8 insertions(+), 10 deletions(-) Thanks, patch is committed to master. I'll hazard a guess as to why things worked before but now. malloc/free don't work with classes that have virtual functions. Perhaps, between Android versions, the classes transitioned from C-style structs to classes with virtual functions ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] Test, please ignore (v7)
Test, please ignore. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] waffle-1.3.rc1
A new pre-release has been tagged, waffle-1.3.rc1. The real waffle-1.3.0 will get released on Thu 26 Sept. I request your assistance in testing it on your favorite platform. Specifically, I need assistance in testing Android and Mac OS 10.7. As long as the test application examples/gl_basic works on those platforms, then I think the waffle is ready for release. I tested this rc on Max OS 10.7 and Linux (GLX, X/EGL, GBM, Wayland) by running `make check-func` and playing with examples/gl_basic. I also did a full Piglit run under Gnome Shell and verified there exist no Piglit regressions. The waffle-1.3.0 release will introduce the ability create forward-compatible and debug contexts as well as improved support for Mac OS. Details below. New Features - [all platforms] Support for creating forward-compatible OpenGL contexts. See the documentation for WAFFLE_CONTEXT_FORWARD_COMPATIBLE in manpage waffle_config(3). - [all platforms] Support for creating OpenGL and OpenGL ES debug contexts. See the documentation for WAFFLE_CONTEXT_DEBUG in manpage waffle_config(3). - [cgl] Improved support on Mac OS for choosing the OpenGL context version. This will be needed for Piglit to transparently run OpenGL 3.1 tests on Mac OS. Previously, Waffle required the client to choose exactly either 3.2 or leave the context version at its default value, 1.0. Now, Waffle emulates the behavior of EGL: the client may request any context flavor, and Waffle will promote the requested flavor to the latest supported flavor backwards-compatible with the requested one). ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH v2 1/4] waffle utils: add wflinfo utility
On Mon, Dec 23, 2013 at 09:48:33PM -0800, Jordan Justen wrote:
glxinfo for waffle, but using the command line interface
of waffle's gl_basic test.
v2:
* Various cleanups suggested by Chad
* Print context flags rather than verifying them.
* Only print extensions when --verbose is used
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
Note: This has only been tested with platforms gbm, glx and x11_egl.
It has only been tested with the Intel Mesa driver.
Regarding Mac support... When review finishes on this patch, I'll commit
it after verifying it doesn't break the Mac build. Then I'll fix any
Mac bugs myself in follow-up patches.
[snip]
+static void __attribute__((noreturn))
+error_printf(const char *fmt, ...)
+{
+va_list ap;
+
+fflush(stdout);
+
+va_start(ap, fmt);
+fprintf(stderr, wflinfo: error: );
+vfprintf(stderr, fmt, ap);
+fprintf(stderr, \n);
+va_end(ap);
+
+exit(EXIT_FAILURE);
+}
Need a newline here between functions.
+static void __attribute__((noreturn))
+usage_error_printf(const char *fmt, ...)
+{
+fflush(stdout);
+fprintf(stderr, wflinfo: usage error);
+
+if (fmt) {
+va_list ap;
+va_start(ap, fmt);
+fprintf(stderr, : );
+vfprintf(stderr, fmt, ap);
+va_end(ap);
+}
+
+fprintf(stderr, \n);
+fprintf(stderr, \n);
+fprintf(stderr, %s, usage_message);
+
+exit(EXIT_FAILURE);
+}
[snip]
+static void
+print_extensions(bool use_stringi)
+{
+GLint count = 0, i;
+const char *ext;
+
+printf(OpenGL extensions: );
+if (use_stringi) {
+glGetIntegerv(GL_NUM_EXTENSIONS, count);
+if (glGetError() != GL_NO_ERROR) {
+printf(GL ERROR);
The space in GL ERROR could confuse applications that parse wflinfo's
output, because extension names do not contain spaces. Let's instead
print GL_ERROR.
Also, this GL_ERROR lacks a trailing newline, the lack of which will
corrupt the next line of output.
To ensure the presence of a newline, I think it best to place
`printf(\n)` at the bottom of the function. This requires that puts()
be replaced by printf() and that the \n be removed from
`printf(%s%s...)`. Of course, there are other ways to ensure the
newline; choose whivever method you think best.
+} else {
+for (i = 0; i count; i++) {
+ ext = (const char *) glGetStringi(GL_EXTENSIONS, i);
+ if (glGetError() != GL_NO_ERROR)
+ ext = GL ERROR;
Same as above regarding s/GL ERROR/GL_ERROR/.
+ printf(%s%s, ext, (i + 1) count ? : \n);
+}
+}
+} else {
+const char *extensions = (const char *) glGetString(GL_EXTENSIONS);
+if (glGetError() != GL_NO_ERROR)
+printf(GL ERROR);
Same as above regarding s/GL ERROR/GL_ERROR/.
+else
+puts(extensions);
+}
+}
+
+static void
+print_context_flags(void)
+{
+static struct {
+GLint flag;
+char *str;
+} flags[] = {
+{ GL_CONTEXT_FLAG_FORWARD_COMPATIBLE_BIT, FORWARD_COMPATIBLE },
+{ GL_CONTEXT_FLAG_DEBUG_BIT, DEBUG },
+{ GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT_ARB, ROBUST_ACCESS },
+};
+int flag_count = sizeof(flags) / sizeof(flags[0]);
+GLint context_flags = 0;
+
+glGetIntegerv(GL_CONTEXT_FLAGS, context_flags);
A convention throughout waffle's code is to avoid excessive indentation
by returning early on errors and moving the normal codepath out of the
if-block. Please do that here on glGetError(), because the main portion
of this function unnecessarily resides in an if-block.
+if (glGetError() == GL_NO_ERROR) {
+printf(OpenGL context flags:);
+if (context_flags == 0) {
+printf( (none)\n);
+return;
+}
+
+for (int i = 0; i flag_count; i++) {
+if ((flags[i].flag context_flags) != 0) {
+printf( %s, flags[i].str);
+context_flags = context_flags ~flags[i].flag;
+}
+}
+for (int i = 0; context_flags != 0; context_flags = 1, i++) {
+if ((context_flags 1) != 0) {
+printf( 0x%x, 1 i);
+}
+}
+printf(\n);
+}
+}
+
+/// @brief Print out information about the context that was created.
+static bool
+print_wflinfo(struct options *opts)
+{
+
Remove the above extra newline after the opening brace.
+while(glGetError() != GL_NO_ERROR)
+/* Clear all errors */;
Ooh! That dangling ';' is just waiting to become a bug. Please surround
the while-body with braces to prevent future bugs.
while (glGetError() != GL_NO_ERROR) {
/* Clear all errors */
}
+
+const char *vendor = (const char *) glGetString(GL_VENDOR);
+if (glGetError() != GL_NO_ERROR || vendor == NULL)
+vendor = GL ERROR;
+
Re: [waffle] [PATCH v2 3/4] waffle utils: add wflinfo man page
On Mon, Dec 23, 2013 at 09:48:35PM -0800, Jordan Justen wrote: Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- .gitignore| 1 + doc/html/man/index.html | 3 + man/.gitignore| 1 + man/common/author-jordan.l.justen.xml | 8 ++ man/html.cmake| 2 + man/html.xsl | 8 ++ man/manpages.cmake| 5 + man/waffle.7.xml | 1 + man/wflinfo.1.xml | 182 ++ 9 files changed, 211 insertions(+) create mode 100644 man/common/author-jordan.l.justen.xml create mode 100644 man/wflinfo.1.xml This patch is very thorough :) And I didn't know about the replaceable element. It looks good to me, except for one thing. I inspected several manpages in volume 1, [git(1), ls(1), gdb(1), vim(1)], and in each the Description immediately follows the Synopsis and occurs before any section about Options. The wflinfo manpage should follow that same tradition. That is, the section ordering should change from + refsect1 +titleRequired Parameters/title + refsect1 +titleOptions/title + refsect1 +titleDescription/title to + refsect1 +titleDescription/title + refsect1 +titleRequired Parameters/title + refsect1 +titleOptions/title With that change, Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/4] wflinfo: Clean usage text
Jordan, I committed this series to master. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH] wfinfo: Add short option -h for --help
Document it in the manpage too.
CC: Jordan Justen jordan.l.jus...@intel.com
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
man/wflinfo.1.xml | 1 +
src/utils/wflinfo.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/man/wflinfo.1.xml b/man/wflinfo.1.xml
index e2a590d..a5f1715 100644
--- a/man/wflinfo.1.xml
+++ b/man/wflinfo.1.xml
@@ -147,6 +147,7 @@
/listitem
/varlistentry
varlistentry
+termoption-h/option/term
termoption--help/option/term
listitem
para
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index dd70a4e..07f3513 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -83,7 +83,7 @@ static const char *usage_message =
--debug-context\n
Create a debug context.\n
\n
---help\n
+-h, --help\n
Print wflinfo usage information.\n
\n
Examples:\n
@@ -102,7 +102,7 @@ enum {
OPT_VERBOSE = 'v',
OPT_DEBUG_CONTEXT,
OPT_FORWARD_COMPATIBLE,
-OPT_HELP,
+OPT_HELP = 'h',
};
static const struct option get_opts[] = {
@@ -319,7 +319,7 @@ parse_args(int argc, char *argv[], struct options *opts)
opterr = 0;
while (loop_get_opt) {
-int opt = getopt_long(argc, argv, a:p:vV:, get_opts, NULL);
+int opt = getopt_long(argc, argv, a:hp:vV:, get_opts, NULL);
switch (opt) {
case -1:
loop_get_opt = false;
--
1.8.5.3
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] waffle for android-4.1.2_r1
Juha and Arun,
I posted this patch on a temporary branch for your testing
'tmp-android-fixes'.
https://github.com/chadversary/waffle/commits/tmp-android-fixes
After Juha-Pekka tests the patch, I'll commit.
-Chad
On Fri, Feb 28, 2014 at 12:14:38PM +0530, Arun Sl wrote:
Hello Juha,
Please find the patch I have come up with.
Thanks Regards
Arun S L
From: Juha-Pekka Heikkilä juha-pekka.heikk...@linux.intel.com
To: Arun Sl arun...@tcs.com
Cc: waffle@lists.freedesktop.org
Date: 02/27/2014 06:14 PM
Subject: Re: [waffle] waffle for android-4.1.2_r1
━━━
Hi Arun,
In the beginning of the file droid_surfaceflingerlink.cpp you can see how
to juggle with the different Android versions using #if/#else's. Would be
superb if you could make your fix into a patch format, I can test it on
JellyBean Android how it work there.
/Juha-Pekka
On Thu, February 27, 2014 12:08 pm, Arun Sl wrote:
Hello Again,
Just fixed the issue:
This seems to be something to do with the order in which the arguments are
given to createSurface that was causing the issue.
pANWContainer-surface_control =
pSFContainer-composer_client-createSurface(
String8(Waffle Surface),0,
droid_magic_surface_width, droid_magic_surface_height,
PIXEL_FORMAT_RGB_888);
Now this is solved.
But the code need to branch based on Android version make it work on old
android versions as well as newer ones.
Thanks Regards
Arun S L
From:
Arun Sl/HYD/TCS
To:
waffle@lists.freedesktop.org
Date:
02/27/2014 03:12 PM
Subject:
waffle for android-4.1.2_r1
Hello,
I have tried latest waffle against android-4.1.2_r1 but it segfaults.
So to avoid the same, I did make the following changes:
struct wcore_window*
droid_window_create(struct wcore_platform *wc_plat,
struct wcore_config *wc_config,
int width,
int height)
{
struct droid_window *self;
struct wegl_config *config = wegl_config(wc_config);
struct droid_display *dpy = droid_display(wc_config-display);
bool ok = true;
self = wcore_calloc(sizeof(*self));
if (self == NULL)
return NULL;
self-pANWContainer = droid_create_surface(width, height,
dpy-pSFContainer);
if (!self-pANWContainer)
goto error1;
ok = wegl_window_init(self-wegl, wc_config,
(intptr_t) *((intptr_t*)(self-pANWContainer)));
if (!ok)
goto error;
return self-wegl.wcore;
error:
droid_window_destroy(self-wegl.wcore);
error1:
return NULL;
}
The waffle is still not working against even gl_basic, I am getting the
following error:
gl_basic --platform=android --api=gles2
gl_basic: error: WAFFLE_ERROR_UNKNOWN: Unable to get
android::SurfaceControl
Can anyone guide me here?
Thanks Regards
Arun S L
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] waffle for android-4.1.2_r1
Arun, I committed your changes to master.
As Juha said, when contributing patches to public projects, please
create your patches with `git format-patch`. If you do that, it makes
the maintainer's job (that's me) much easier, because I can quickly
apply your patches git `git am`. If you're feeling extra nice, you could
even send them with git-send-email ;), but I work with attached patches
too.
If the git-am and git-format-patch commands are new to you, this
page has quick, clear tutorial.
http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project
Thanks,
Chad
On Fri, Feb 28, 2014 at 02:46:35PM +0200, Juha-Pekka Heikkilä wrote:
Hi Arun,
the code changes look good to me. It compile against JellyBean. I looked
up and see it was commit d49cc713332b565ad4913ef859972b82a3bca358 which
changed this to work for JB tree but broke older versions in the process.
The patch you would get in correct format with git. I am not great user of
git but the way I do it is to first do git status to see the changed
files. Then for each file you wish to add to the patch you do git add
file and once all files are added you do git commit -s which ask you
to write the commit message. For commit messages you can see from git
log how is the preferred style for the tree. After committing the change
to your local tree you do git format-patch -1 which give you the last
commit in nice format. The produced patch file is easy to commit to other
trees with git while maintaining the owner, that patch file you send to
mailing list.
/Juha-Pekka
On Fri, February 28, 2014 8:44 am, Arun Sl wrote:
Hello Juha,
Please find the patch I have come up with.
Thanks Regards
Arun S L
From:
Juha-Pekka Heikkilä juha-pekka.heikk...@linux.intel.com
To:
Arun Sl arun...@tcs.com
Cc:
waffle@lists.freedesktop.org
Date:
02/27/2014 06:14 PM
Subject:
Re: [waffle] waffle for android-4.1.2_r1
Hi Arun,
In the beginning of the file droid_surfaceflingerlink.cpp you can see how
to juggle with the different Android versions using #if/#else's. Would be
superb if you could make your fix into a patch format, I can test it on
JellyBean Android how it work there.
/Juha-Pekka
On Thu, February 27, 2014 12:08 pm, Arun Sl wrote:
Hello Again,
Just fixed the issue:
This seems to be something to do with the order in which the arguments
are
given to createSurface that was causing the issue.
pANWContainer-surface_control =
pSFContainer-composer_client-createSurface(
String8(Waffle Surface),0,
droid_magic_surface_width, droid_magic_surface_height,
PIXEL_FORMAT_RGB_888);
Now this is solved.
But the code need to branch based on Android version make it work on old
android versions as well as newer ones.
Thanks Regards
Arun S L
From:
Arun Sl/HYD/TCS
To:
waffle@lists.freedesktop.org
Date:
02/27/2014 03:12 PM
Subject:
waffle for android-4.1.2_r1
Hello,
I have tried latest waffle against android-4.1.2_r1 but it segfaults.
So to avoid the same, I did make the following changes:
struct wcore_window*
droid_window_create(struct wcore_platform *wc_plat,
struct wcore_config *wc_config,
int width,
int height)
{
struct droid_window *self;
struct wegl_config *config = wegl_config(wc_config);
struct droid_display *dpy = droid_display(wc_config-display);
bool ok = true;
self = wcore_calloc(sizeof(*self));
if (self == NULL)
return NULL;
self-pANWContainer = droid_create_surface(width, height,
dpy-pSFContainer);
if (!self-pANWContainer)
goto error1;
ok = wegl_window_init(self-wegl, wc_config,
(intptr_t)
*((intptr_t*)(self-pANWContainer)));
if (!ok)
goto error;
return self-wegl.wcore;
error:
droid_window_destroy(self-wegl.wcore);
error1:
return NULL;
}
The waffle is still not working against even gl_basic, I am getting the
following error:
gl_basic --platform=android --api=gles2
gl_basic: error: WAFFLE_ERROR_UNKNOWN: Unable to get
android::SurfaceControl
Can anyone guide me here?
Thanks Regards
Arun S L
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
[waffle] [PATCH] egl: Fix creation of compatibility contexts
From: Chad Versace c...@kiwitree.net
wegl_context_create() ignored wcore_config_attrs::context_profile and
never set EGL_CONTEXT_OPENGL_PROFILE_MASK_KHR. The default value of
EGL_CONTEXT_OPENGL_PROFILE_MASK_KHR is
EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR. Therefore, for context versions
= 3.2, wegl_context_create() always created a core context.
This patch fixes wegl_context_create() to inspect
wcore_config_attrs::context_profile and set
EGL_CONTEXT_OPENGL_PROFILE_MASK_KHR accordingly.
(Whoo! Waffle has an issue tracker now, and the 'Fixes' tag below will
automatically close the issue when patch hits master!)
Fixes: https://github.com/waffle-gl/waffle/issues/1
Reported-by: Jordan Justen jordan.l.jus...@intel.com
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
Jordan, this patch is untested because I have access to no Linux computer this
weekend. When you validate the patch, I'll commit it.
The patch lives on my personal branch issues/1/fix-egl-compat-profile [1],
exact commit at https://github.com/chadversary/waffle/commit/ba6e561.
[1] https://github.com/chadversary/waffle/tree/issues/1/fix-egl-compat-profile
src/waffle/egl/wegl_context.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/waffle/egl/wegl_context.c b/src/waffle/egl/wegl_context.c
index 50b31c6..e189ffd 100644
--- a/src/waffle/egl/wegl_context.c
+++ b/src/waffle/egl/wegl_context.c
@@ -70,6 +70,7 @@ create_real_context(struct wegl_config *config,
int32_t waffle_context_api = attrs-context_api;
EGLint attrib_list[64];
EGLint context_flags = 0;
+EGLint profile_mask = 0;
int i = 0;
if (attrs-context_debug) {
@@ -118,6 +119,27 @@ create_real_context(struct wegl_config *config,
return EGL_NO_CONTEXT;
}
+switch (attrs-context_profile) {
+case WAFFLE_NONE:
+profile_mask = 0;
+break;
+case WAFFLE_CONTEXT_CORE_PROFILE:
+profile_mask = EGL_CONTEXT_OPENGL_CORE_PROFILE_BIT_KHR;
+break;
+case WAFFLE_CONTEXT_COMPATIBILITY_PROFILE:
+profile_mask = EGL_CONTEXT_OPENGL_COMPATIBILITY_PROFILE_BIT_KHR;
+break;
+default:
+wcore_error_internal(attrs-context_profile has bad value %#x,
+ attrs-context_profile);
+return EGL_NO_CONTEXT;
+}
+
+if (profile_mask != 0) {
+attrib_list[i++] = EGL_CONTEXT_OPENGL_PROFILE_MASK_KHR;
+attrib_list[i++] = profile_mask;
+}
+
if (context_flags != 0) {
attrib_list[i++] = EGL_CONTEXT_FLAGS_KHR;
attrib_list[i++] = context_flags;
--
1.8.5.3
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] egl: Fix creation of compatibility contexts
On Sat, Mar 8, 2014 at 6:43 PM, Jordan Justen jljus...@gmail.com wrote: On Sat, Mar 8, 2014 at 9:39 AM, Chad Versace c...@chad-versace.us wrote: From: Chad Versace c...@kiwitree.net Jordan, this patch is untested because I have access to no Linux computer this weekend. When you validate the patch, I'll commit it. Tested-by: Jordan Justen jordan.l.jus...@intel.com Should this be done only for OpenGL = 3.2 like in glx_context.c? The code in wcore_config_attrs.c emits an error if the use requests a core or compat profile for GL 3.2 or for any version of ES. So, it isn't strictly necessary to duplicate that check in wegl_context.c. wcore_config_attrs.c ensures that profile is used only for GL = 3.2. The code in glx_context.c looks substantially different because GLX also has a profile bit for ES. Having said all that, I prefer that code look correct in *local* context. But, in local context, the code in my patch looks incorrect. I'll send a v2 patch that resembles the code in glx_context.c. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH 0/6] wflinfo: Make wflinfo understand OpenGL 3.1 profiles
After this series, the following all do what the user wants them to do. wflinfo --api=gl --version=3.1 wflinfo --api=gl --version=3.1 --profile=none wflinfo --api=gl --version=3.1 --profile=core wflinfo --api=gl --version=3.1 --profile=compat Likewise, if the user provided a profile but no version, like this... wflinfo --api=gl --profile=core wflinfo --api=gl --profile=compat then wflinfo will also try creating an OpenGL 3.1 context. DISCLAIMER: I've only tested these patches on Intel Ivybride, which exposes only core profile for OpenGL 3.1 and above. Someone really needs to test this on a system that exposes an OpenGL 3.1 compatibility context, but I don't have access to one. If no one steps up to test that, then we can commit now and fix bugs later. This series lives on my wflinfo-3.1-v04 branch at https://github.com/chadversary/waffle/tree/wflinfo-3.1-v04 I believe this is final feature needed for waffle-1.4. So, after this series lands and the few remaining 1.4 blocker issues on https://github.com/waffle-gl/waffle/issues?milestone=1state=open get resolved, I'll send out a wafle-1.4 release candidate announcement. Chad Versace (6): wflinfo: Don't modify struct options after initialization wflinfo: Cleanup signature of wflinfo_try_create_context() wflinfo: Cleanup signature of wflinfo_create_context() wflinfo: Replace s/-1/WAFFLE_DONT_CARE/ when relevant wflinfo: Distinguish between cmdline options and func options wflinfo: Make wflinfo understand OpenGL 3.1 profiles src/utils/wflinfo.c | 355 +--- 1 file changed, 307 insertions(+), 48 deletions(-) -- 1.9.0 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH 1/6] wflinfo: Don't modify struct options after initialization
parse_args() initializes global options. After that, options should be
immutable. To ensure that, constify each occurence of struct options as
a function parameter.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
src/utils/wflinfo.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index 7e3dd48..4a105be 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -497,7 +497,7 @@ print_context_flags(void)
/// @brief Print out information about the context that was created.
static bool
-print_wflinfo(struct options *opts)
+print_wflinfo(const struct options *opts)
{
while(glGetError() != GL_NO_ERROR) {
/* Clear all errors */
@@ -601,7 +601,7 @@ removeXcodeArgs(int *argc, char **argv)
#endif // __APPLE__
static struct waffle_context *
-wflinfo_try_create_context(struct options *opts,
+wflinfo_try_create_context(const struct options *opts,
struct waffle_config **config,
struct waffle_display *dpy,
bool exit_on_fail)
@@ -688,7 +688,7 @@ fail:
#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
static struct waffle_context *
-wflinfo_create_context(struct options *opts,
+wflinfo_create_context(const struct options *opts,
struct waffle_config **config,
struct waffle_display *dpy)
{
@@ -705,10 +705,11 @@ wflinfo_create_context(struct options *opts,
static int known_gl_profile_versions[] =
{ 32, 33, 40, 41, 42, 43, 44 };
+struct options tmp_opts = *opts;
+
for (int i = ARRAY_SIZE(known_gl_profile_versions) - 1; i = 0; i--) {
-opts-context_version = known_gl_profile_versions[i];
-ctx = wflinfo_try_create_context(opts, config, dpy, false);
-opts-context_version = -1;
+tmp_opts.context_version = known_gl_profile_versions[i];
+ctx = wflinfo_try_create_context(tmp_opts, config, dpy, false);
if (ctx)
break;
}
--
1.9.0
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] waffle man pages 80 columns
On Sun, Apr 27, 2014 at 03:33:36PM -0700, Jordan Justen wrote: Debian's lintian tool is flagging a manpage-has-errors-from-man warning on: * waffle_config.3 * waffle_context.3 * waffle_display.3 * waffle_is_extension_in_string.3 * waffle_window.3 I guess the issue is that these man pages have issues with reflowing lines 80 characters. Have you determined which lines are problematic? I looked at `man waffle_context` and `man waffle_is_extension_in_string` in a skinny terminal of about 50 columns. The only problems I see are long urls (which we can't do anything about) and the function prototypes. The function prototypes look *awful* in a skinny terminal. So... what's wrong with the XML for prototypes? I'm no XML or Docbook or manpage expert. So I'm lost here too. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 5/6] wflinfo: Distinguish between cmdline options and func options
On Mon, Apr 28, 2014 at 11:45:41PM -0700, Jordan Justen wrote:
On Mon, Apr 28, 2014 at 8:43 PM, Chad Versace
static bool
-wflinfo_try_create_context(const struct options *opts,
- struct waffle_display *dpy,
+wflinfo_try_create_context(struct waffle_display *dpy,
+ struct wflinfo_config_attrs attrs,
I prefer pointers to structs for function parameters. (I don't like
the implicit copy on call.)
But, either way:
Reviewed-by: Jordan Justen jordan.l.jus...@intel.com
I usually dislike pass-struct-by-value too. The original patch passed by
pointer, but it was messier than pass-by-value. The function calls
basically followed this pattern:
void
foo(const struct wflinfo_config_attrs *attrs)
{
...;
struct wflinfo_config_attrs tmp_attrs = *attrs;
tmp_attrs.version = abc;
tmp_attrs.profile = xyz;
bar(..., tmp_attrs);
}
Passing by value simplified it to:
void
foo(struct wflinfo_config_attrs attrs)
{
...;
attrs.version = abc;
attrs.profile = xyz;
bar(..., attrs);
}
Maybe the difference doesn't seem significant in this little example,
but in the real patch it looked a lot messier than the pass-by-value
idiom.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 2/2] wflinfo: Properly handle minor versions 9
On Wed, Apr 30, 2014 at 10:27:04AM -0700, Jordan Justen wrote:
On Tue, Apr 29, 2014 at 1:12 PM, Dylan Baker baker.dyla...@gmail.com wrote:
On Tuesday, April 29, 2014 08:39:19 Jordan Justen wrote:
Previously -V 1.40 would be treated the same as -V 5.0.
Instead, whenever a minor version is requested greater
than 9, bump the major version, and use 0 for the minor
version.
This leads to -V 1.40 being interpreted as -V 2.0.
Alternatively, we might treat minor versions greater
than 9 as an error.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/utils/wflinfo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index 386bdd0..982311d 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -336,6 +336,12 @@ parse_args(int argc, char *argv[], struct options
*opts)
usage_error_printf('%s' is not a valid OpenGL version,
optarg);
}
+ if (minor 9) {
+ // If a minor version greater than 9 was requested, then
+ // bump the major version and use 0 for the minor.
+ major++;
+ minor = 0;
+ }
opts-context_version = 10 * major + minor;
break;
}
As a consumer of wflinfo I would prefer to see a bad version treated as an
error.
I could see wflinfo deciding that minor 9 is always an error.
But, I don't want to check the version again a known set of good
versions because:
* New spec/driver versions could be used with older wflinfo builds
* Different versions per API
* I'd rather leave it to libwaffle/driver to reject the version
Maybe a better fix is to not store major/minor from the user as major
* 10 + minor.
I agree with Dylan. Bad versions should fail. If wflinfo helpfully
cleans up bad versions, then the user may get an unwanted surprise.
I agree with Jordan. Let's avoid hardcoding a list of known GL versions
if at all possible. And wflinfo shouldn't be the arbiter of what's
a good and bad GL version. libwaffle already has plenty of code for
that. These types of checks can get surprisingly complicated (otherwise,
libwaffle wouldn't need to exist), and we should avoid duplicating that
code.
Jordan, I think splitting the major and minor versions into separate
variables context_major_version/context_minor_version is a good idea.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/2] wflinfo: Don't allow negative version numbers
On Tue, Apr 29, 2014 at 08:39:18AM -0700, Jordan Justen wrote: Previously, -V 4.-8 would be treated the same as -V 3.2. WTF?!? Reviewed-by: Chad Versace chad.vers...@linux.intel.com (Jordan, commit the patch with your new superpowers. It's your patch afterall). Hmm... wflinfo keeps getting bigger, especially with the 3.1 magic. It surely has more bugs waiting discover. It really needs to be unit tested against a mocked driver. I wish I had time to write the mocks... oh well. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/6] wflinfo: Make wflinfo understand OpenGL 3.1 profiles
On Mon, Apr 28, 2014 at 11:23:13PM -0700, Jordan Justen wrote: On Mon, Apr 28, 2014 at 8:43 PM, Chad Versace chad.vers...@linux.intel.com wrote: After this series, the following all do what the user wants them to do. wflinfo --api=gl --version=3.1 wflinfo --api=gl --version=3.1 --profile=none wflinfo --api=gl --version=3.1 --profile=core wflinfo --api=gl --version=3.1 --profile=compat Likewise, if the user provided a profile but no version, like this... wflinfo --api=gl --profile=core wflinfo --api=gl --profile=compat then wflinfo will also try creating an OpenGL 3.1 context. DISCLAIMER: I've only tested these patches on Intel Ivybride, which exposes only core profile for OpenGL 3.1 and above. Someone really needs to test this on a system that exposes an OpenGL 3.1 compatibility context, but I don't have access to one. If no one steps up to test that, then we can commit now and fix bugs later. Patches 1-4 Reviewed-by: Jordan Justen jordan.l.jus...@intel.com These results (on nvidia with GL 4.4) could be better: $ bin/wflinfo -p glx -a gl -V 3.1 --profile=core Waffle error: 0x0 WAFFLE_NO_ERROR $ bin/wflinfo -p glx -a gl -V 3.1 --profile=compat Waffle error: 0x0 WAFFLE_NO_ERROR Removing -V works as expected though. origin/master gives: $ bin/wflinfo -p glx -a gl -V 3.1 --profile=core Waffle error: 0x8 WAFFLE_ERROR_BAD_ATTRIBUTE: for OpenGL 3.2, WAFFLE_CONTEXT_PROFILE must be WAFFLE_NONE $ bin/wflinfo -p glx -a gl -V 3.1 --profile=compat Waffle error: 0x8 WAFFLE_ERROR_BAD_ATTRIBUTE: for OpenGL 3.2, WAFFLE_CONTEXT_PROFILE must be WAFFLE_NONE Ivybridge looks good.Here's my output. $ bin/wflinfo -p gbm -a gl -V 3.1 --profile=core Wflinfo: Creation of an OpenGL = 3.1 context succeeded, but it had the wrong profile. Fallback to requesting an OpenGL = 3.2 context, which is guaranteed to have the correct profile if context creation succeeds. Waffle platform: gbm Waffle api: gl OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile OpenGL version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-410d7ae) OpenGL context flags: 0x0 $ bin/wflinfo -p gbm -a gl -V 3.1 --profile=compat Wflinfo: Creation of an OpenGL = 3.1 context succeeded, but it had the wrong profile. Fallback to requesting an OpenGL = 3.2 context, which is guaranteed to have the correct profile if context creation succeeds. Wflinfo error: Failed to create an OpenGL 3.1 or later context with requested profile I'm looking at the code now trying to understand why NVidia fails. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/6] wflinfo: Make wflinfo understand OpenGL 3.1 profiles
On Wed, Apr 30, 2014 at 07:25:39PM -0700, Chad Versace wrote:
On Mon, Apr 28, 2014 at 11:23:13PM -0700, Jordan Justen wrote:
These results (on nvidia with GL 4.4) could be better:
$ bin/wflinfo -p glx -a gl -V 3.1 --profile=core
Waffle error: 0x0 WAFFLE_NO_ERROR
$ bin/wflinfo -p glx -a gl -V 3.1 --profile=compat
Waffle error: 0x0 WAFFLE_NO_ERROR
Removing -V works as expected though.
My best guess is that waffle_make_current() fails here.
// The user cares about the profile. We must bind the context to inspect
// its profile.
//
// Skip window creation. No window is needed when binding an OpenGL = 3.0
// context.
ok = waffle_make_current(dpy, NULL, ctx);
if (!ok) {
error_waffle();
}
On GLX, that doesn't set waffle_error because this code in glx_platform.c is
stupid:
static inline Bool
wrapped_glXMakeCurrent(Display *dpy, GLXDrawable drawable, GLXContext ctx)
{
X11_SAVE_ERROR_HANDLER
Bool ok = glXMakeCurrent(dpy, drawable, ctx);
X11_RESTORE_ERROR_HANDLER
return ok;
}
Can you confirm if my guess is correct? Maybe by dropping this into the GLX
function:
if (!ok) {
wcore_errorf(WAFFLE_ERROR_UNKNOWN,
Chad forgot to catch GLX errors);
}
Well... I may have forgot to catch GLX errors, but it used to be worse. Xlib's
default error handler would kill the process on GLX error.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 2/6] wflinfo: Cleanup signature of wflinfo_try_create_context()
On Sat, May 03, 2014 at 12:36:49AM +0100, Emil Velikov wrote: On 29/04/14 04:43, Chad Versace wrote: The function creates and returns two objects: a context and a config. The context is the function's return value, and the config is an out parameter. Functions with asymmetric returns, I find awkard. Fix the signature to return both objects as out parameters. Hi Chad, Rather silly question (as I'm getting through the codebase). Wouldn't it be better if use return int over bool ? The function name does not imply that a bool is returned, plus it gives us the flexibility of returning appropriate (currently unneeded) errno. In designing the Waffle's public API, I tried to follow the example of EGL, which returns either NULL or false on failure. This design then affected Waffle's internal APIs too. In retrospect, I think choosing to model Waffle's error reporting on EGL's model may have been a clumsy choice. If Waffle 2.0 ever happens, then that would be a good time to reconsider the approach. In general, returning int rather than bool does provide more flexibility for reporting status, but I chose to use bool in this patch to be consistent with the rest of Waffle. If waffle_try_create_context() returned an enum that indicated the cause of failure, then we could possibly eliminate the exit_on_fail parameter. I would welcome such a cleanup. I wish the public API, though, to remain consistent in how it reports error. Return NULL or false, then the user inspects the waffle_error_info if he wants more information, similar to eglGetError(). ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 2/4] waffle internals: Add helper functions for attrs versions
On Thu, May 08, 2014 at 10:13:59PM -0700, Chad Versace wrote: On Sun, May 04, 2014 at 10:14:19AM -0700, Jordan Justen wrote: These functions make it easier to compare against known OpenGL and OpenGLES versions since all known and expected future versions have a minor version = 9. For example, to check that the attrs struct has a version = 3.2, use wcore_config_attrs_version_above_or_equals(attrs, 32) Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- src/waffle/core/wcore_config_attrs.c | 48 src/waffle/core/wcore_config_attrs.h | 25 +++ 2 files changed, 73 insertions(+) +wcore_config_attrs_version_equals( +wcore_config_attrs_version_above( +wcore_config_attrs_version_above_or_equals( +wcore_config_attrs_version_below( +wcore_config_attrs_version_below_or_equals( The function names feel overly verbose. I prefer to rename them to wcore_config_attrs_version_eq wcore_config_attrs_version_gt wcore_config_attrs_version_ge wcore_config_attrs_version_lt wcore_config_attrs_version_le But I don't want to block the series over it. Renamed or not, this patch is Reviewed-by: Chad Versace chad.vers...@linux.intel.com Oops, forgot something. Please prefix the patch subject as core, not waffle internals. Take a quick look at the following to see the pattern: git log src/waffle/core git log src/waffle/glx git log src/waffle/egl git log src/waffle/x11 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [website PATCH 1/2] Move release tarballs from chad's freedesktop home dir to github
Change the url for each file waffle-${version}.tar.xz.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
releases.html | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/releases.html b/releases.html
index c9d36bf..ffbd87b 100644
--- a/releases.html
+++ b/releases.html
@@ -17,7 +17,7 @@
ul
liDate: 2013-09-30/li
lia
href=files/release/waffle-1.3.0/waffle-1.3.0-announcement.txtAnnouncement
email/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.3.0/waffle-1.3.0.tar.xz;waffle-1.3.0.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.3.0/waffle-1.3.0.tar.xz;waffle-1.3.0.tar.xz/a/li
lia
href=files/release/waffle-1.3.0/waffle-1.3.0.tar.xz.sigwaffle-1.3.0.tar.xz.sig/a/li
lia
href=files/release/waffle-1.3.0/waffle-1.3.0.sha256sumswaffle-1.3.0.sha256sums/a/li
/ul
@@ -26,7 +26,7 @@
ul
liDate: 2013-08-08/li
lia
href=files/release/waffle-1.2.3/waffle-1.2.3-announcement.txtAnnouncement
email/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.2.3/waffle-1.2.3.tar.xz;waffle-1.2.3.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.2.3/waffle-1.2.3.tar.xz;waffle-1.2.3.tar.xz/a/li
lia
href=files/release/waffle-1.2.3/waffle-1.2.3.tar.xz.sigwaffle-1.2.3.tar.xz.sig/a/li
lia
href=files/release/waffle-1.2.3/waffle-1.2.3.sha256sumswaffle-1.2.3.sha256sums/a/li
/ul
@@ -34,7 +34,7 @@
lia name=1.2.2 href=#1.2.2h31.2.2/h3/a
ul
lia
href=http://raw.githubusercontent.com/waffle-gl/waffle/1.2/doc/release-notes/waffle-1.2.2.txt;Release
notes/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.2.2/waffle-1.2.2.tar.xz;waffle-1.2.2.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.2.2/waffle-1.2.2.tar.xz;waffle-1.2.2.tar.xz/a/li
lia
href=files/release/waffle-1.2.2/waffle-1.2.2.tar.xz.sigwaffle-1.2.2.tar.xz.sig/a/li
lia
href=files/release/waffle-1.2.2/waffle-1.2.2.sha256sumswaffle-1.2.2.sha256sums/a/li
/ul
@@ -42,7 +42,7 @@
lia name=1.2.1 href=#1.2.1h31.2.1/h3/a
ul
lia
href=http://raw.githubusercontent.com/waffle-gl/waffle/1.2/doc/release-notes/waffle-1.2.1.txt;Release
notes/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.2.1/waffle-1.2.1.tar.xz;waffle-1.2.1.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.2.1/waffle-1.2.1.tar.xz;waffle-1.2.1.tar.xz/a/li
lia
href=files/release/waffle-1.2.1/waffle-1.2.1.tar.xz.sigwaffle-1.2.1.tar.xz.sig/a/li
lia
href=files/release/waffle-1.2.1/waffle-1.2.1.sha256sumswaffle-1.2.1.sha256sums/a/li
/ul
@@ -50,7 +50,7 @@
lia name=1.2.0 href=#1.2.0h31.2.0/h3/a
ul
lia
href=http://raw.githubusercontent.com/waffle-gl/waffle/1.2/doc/release-notes/waffle-1.2.0.txt;Release
notes/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.2.0/waffle-1.2.0.tar.xz;waffle-1.2.0.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.2.0/waffle-1.2.0.tar.xz;waffle-1.2.0.tar.xz/a/li
lia
href=files/release/waffle-1.2.0/waffle-1.2.0.tar.xz.sigwaffle-1.2.0.tar.xz.sig/a/li
lia
href=files/release/waffle-1.2.0/waffle-1.2.0.sha256sumswaffle-1.2.0.sha256sums/a/li
/ul
@@ -58,7 +58,7 @@
lia name=1.1.2 href=#1.1.2h31.1.2/h3/a
ul
lia
href=http://raw.githubusercontent.com/waffle-gl/waffle/waffle-1.1.2/doc/release-notes/waffle-1.1.2.txt;Release
notes/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.1.2/waffle-1.1.2.tar.xz;waffle-1.1.2.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.1.2/waffle-1.1.2.tar.xz;waffle-1.1.2.tar.xz/a/li
lia
href=files/release/waffle-1.1.2/waffle-1.1.2.tar.xz.sigwaffle-1.1.2.tar.xz.sig/a/li
lia
href=files/release/waffle-1.1.2/waffle-1.1.2.sha256sumswaffle-1.1.2.sha256sums/a/li
/ul
@@ -66,7 +66,7 @@
lia name=1.1.1 href=#1.1.1h31.1.1/h3/a
ul
lia
href=http://raw.githubusercontent.com/waffle-gl/waffle/waffle-1.1.1/doc/release-notes/waffle-1.1.1.txt;Release
notes/a/li
- lia
href=http://people.freedesktop.org/~chadversary/waffle/files/release/waffle-1.1.1/waffle-1.1.1.tar.xz;waffle-1.1.1.tar.xz/a/li
+ lia
href=https://github.com/waffle-gl/waffle/releases/download/waffle-1.1.1/waffle-1.1.1.tar.xz;waffle-1.1.1.tar.xz/a/li
lia
href=files/release/waffle-1.1.1/waffle-1.1.1.tar.xz.sigwaffle-1.1.1
Re: [waffle] [PATCH 1/3] doc/release-notes: Add waffle-next.txt
On Fri, May 09, 2014 at 09:40:57AM -0700, Jordan Justen wrote: On Thu, May 8, 2014 at 9:31 PM, Chad Versace chad.vers...@linux.intel.com wrote: On Fri, May 02, 2014 at 07:51:07PM -0700, Jordan Justen wrote: Looks good to me, except that the next release will be 1.4.0, not 1.3.90. If you intended it that way, ok. We'll just need to sed the file when renaming it to waffle-1.4.0.txt. Do you think it would be better to use '?', 'TBD', or 'NEXT' as a placeholder for version in waffle-next.txt? I chose 1.3.90 since it seems to be essentially a placeholder version for the next release in the master tree, but we can go with something else too. I prefer NEXT, but it doesn't really matter. If you like 1.3.90 better, then you should go with it. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] pkg arch/mac: Update release tarball urls
On Sat, May 10, 2014 at 02:39:36AM +0100, Emil Velikov wrote: On 09/05/14 18:58, Jordan Justen wrote: Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- Note: I did not test these changes. The arch change looks and work like a charm. I'd be very surprised if MacPorts couldn't handle https. So the Portfile lookds good to me, though I didn't test either. (I tend to test Mac very infrequently). Feel free to slap Reviewed-by/Tested-by: Emil Velikov emil.l.veli...@gmail.com And add mine too. Reviewed-by: Chad Versace chad.vers...@linux.intel.com Just added your tree to git remotes and noticed an interesting commit 2b1b6dca79adf0bf1e5b3df19197b346bd0b5ddf. It mentions a few concerns - installing both multilib + 64bit, keeping them in sync and missing lib32- prefix for the former. Can cook up a patch if anyone is still interested :) Please do. I'm still interested in a multilib PKGBUILD. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] man: Update waffle website url
Reviewed-by: Chad Versace chad.vers...@linux.intel.com On Fri, May 09, 2014 at 11:04:13AM -0700, Jordan Justen wrote: Signed-off-by: Jordan Justen jordan.l.jus...@intel.com --- 'git grep chadversary' shows that the release notes still use the old url. Should these be updated? Let's not modify archived files, such as release notes and email announcements. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] ANNOUNCE: Waffle has moved to Github
Waffle's website and source has moved from Freedesktop to Github. The mailing list will remain at Freedesktop. These are the new urls: source: git://github.com/waffle-gl/waffle gitweb: https://github.com/waffle-gl/waffle issue-tracker: https://github.com/waffle-gl/waffle/issues website:http://www.waffle-gl.org mailing-list: waffle@lists.freedesktop.org ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 4/8] cmake: use the relative path in the install targets
Committed to master. On Sat, May 24, 2014 at 11:51:31PM +0100, Emil Velikov wrote: Otherwise make DESTDIR=... install will not function properly. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- CMakeLists.txt| 4 ++-- doc/CMakeLists.txt| 4 ++-- examples/CMakeLists.txt | 2 +- include/CMakeLists.txt| 2 +- man/html.cmake| 2 +- man/manpages.cmake| 6 +++--- src/waffle/CMakeLists.txt | 2 +- 7 files changed, 11 insertions(+), 11 deletions(-) ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 6/8] waffle: move WAFFLE_API out of the API header
On Sat, May 24, 2014 at 11:51:33PM +0100, Emil Velikov wrote: WAFFLE_API is used to define the symbol visibility and all functions provided by the API must be non-hidden. Thus the define should be used internally in conjunction with the compiler used in order to properly annotate the symbols. Resolves #12: https://github.com/waffle-gl/waffle/issues/12 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- Thanks for the fix. Committed to master and issue #12 closed. I verified the patch by diffing the output of nm before and after. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/8] Move WAFFLE_API out of the public header + misc patches
Patch 7 is committed to master. I added an r-b tag for Jose. On Thu, May 29, 2014 at 11:17:55AM -0700, Jose Fonseca wrote: The Windows specifc change (patch 7) looks good. The rest looks sensible too FWIW, but I'm not the best person to comment, as I'm not yet familiar with the code base. Jose - Original Message - Hi all, Here is a small selection of patches - mostly bugfixes, while going though waffle's existing implementations and working on wgl. The series is available in the for-upstream branch at my github repo https://urldefense.proofpoint.com/v1/url?u=https://github.com/evelikov/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=PKFidBoUqDS1VL09U57pR%2Btw2qErP3G1%2B%2B6XjsEUCE8%3D%0As=f2626a50efbe287b107032398cfe8476bdd29d71fac039eebfec609cd9f97b2f Comments, tips and suggestions are greatly appreciated. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/wafflek=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0Am=PKFidBoUqDS1VL09U57pR%2Btw2qErP3G1%2B%2B6XjsEUCE8%3D%0As=bf956564e315c2ca8e8da1e6e0c16a7758a2c1e8ef7bb1b9c3bfcdf84825b038 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 8/8] core: update wcore_enum_to_string()
On Sat, May 24, 2014 at 11:51:35PM +0100, Emil Velikov wrote: Add a couple of missing cases - PLATFORM_GBM and DL_OPENGL_ES3. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/waffle/core/wcore_util.c | 2 ++ 1 file changed, 2 insertions(+) Committed to master. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble
opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as well.
The
recommended way of doing things under windows seems to be the following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
Options:
- Create a window, choose format, destroy window.
No guarantee that the function will behave the same for
another
window/device_context.
In practice, the odds of this happening are very low.
Just to be clear. This assumption will break when there are multiple GPUs on
the system (each CPU connected to a different display). Anyway, getting
OpenGL to work across multiple GPU (if you move the window from one display
to another bad things will probably happen.)
The reason that wglGetProcAddress requires window/context is because only
then will OPENGL32.DLL know which ICD DLL to load.
Emil, if you decide to create an invisible window internal to Waffle,
maybe the best time to do that is during waffle_display_connect() and
store it in the display. Just a thought, and maybe not a good one.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Wed, Jun 04, 2014 at 11:47:32PM -0700, Jose Fonseca wrote: I thought we wanted to go ahead an provide a binary build for windows, and thus: 1. It should be buildable under Linux using mingw 2. The binary should have a reasonable license situation Didn't we already pretty much have this worked out anyhow? Maybe I misinterpreted things. I always saw mingw as a mean to an end, to facilitate development and get things started (ie, without forcing Emil to obtain and learn to use use a completely new set of tools). And not the end itself (distribute binaries to the world), because: - MinGW often generates bad code, I've seen it happening with Mesa and Apitrace [1]; so I while use MinGW debug binaries all the time, I don't trust MinGW to produce distributable release binaries - MinGW debug information is not understood by MSVC tools, so when an MSVC user debugs its code, it won't be able to get any symbols from waffle if waffle was build with MinGW IMHO, the best sort of binaries are .DLLs produced by MSVC (any version) with statically linked CRT (so no additional dependencies -- no need to ship MSVC redistributables installer). And they should be usable with applications built with anything (MSVC MinGW) Anyway, this is just a mere suggestion. I can always build my own binaries from source if needed. Jose, I had the same interpretation as you. Despite being useful for development, mingw was a mean to an end. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window
On Wed, Jun 04, 2014 at 01:24:38PM -0700, Jose Fonseca wrote:
- Original Message -
On 02/06/14 19:55, Chad Versace wrote:
On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
- Original Message -
- Original Message -
On 24/05/14 20:28, Emil Velikov wrote:
Hi all,
Another round of interesting bits and bulbs.
Bit of an update:
The email came out a bit longer than expected, although it provides a
decent
list of possible solutions. Let me know which one you'll go with.
Four topics sorted by priority - high to low (based on my humble
opinion)
* ChoosePixelFormat - close yet quite different across platforms.
- glXChoosePixelFormat- depends on display (matches waffle's
model).
- CGLChoosePixelFormat- no dependencies.
- {wgl,}ChoosePixelFormat - depends on a device_context/existing
window.
To make things better, wgl functions depend on a current context as
well.
The
recommended way of doing things under windows seems to be the
following:
window_handle = CreateWindow(...)
device_context = GetDC(window_handle);
gl_rendering_context = wglCreateContext(device_context);
wglMakeCurrent (device_handle, gl_rendering_context);
// any of the following
wglGetProcAddress(...)
wglChoosePixelFormat(...)
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
Yep.
AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as
it
allows the PixelFormat to be called prior to the creation of either
window
or
context.
If you could rewrite this problematic portion of Waffle's API, how would
you design it? I'm asking so that, if we do redesign Waffle's API one
day, it can better accommodate Windows and Mac.
One requirement of any API redesign, though, is to preserve the ability
to create a context and render into it without creating a throwaway
surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
ok as long as they are internal to Waffle).
If I understand things correctly surface(egl)/drawable(glx) are not as
clearly
separated in wgl. At least not initially.
Redesign of Waffle's API sounds like an overkill imho, as the only thing we
need is an easier way get from context/config data to window. Otherwise
wcore_(context|config|window) will be dummies and everything will be stored
in
a wcore_display wrapper (wgl_display).
Perhaps the following rough flow illustrates things a bit better
Abstracting across many platforms is always complicated, and even more
if we can't run tests on all of them. So even if we end up
redesigning, it might be better to first get windows to work (even if
that requires a few hacks/assumptions) first, so we can run
tests/examples.
I totally agree. Let's focus on getting Windows working with the current
API, even if it requires imperfect hacks.
glx (in the following example window is optional)
display glx create_context window gl*
wgl (here window is the root, i.e. think of (wgl)window == (glx)display)
window create_context wgl/gl
Currently I shove everything in wgl_display, although a slightly cleaner
approach might be better.
This makes sense to me.
From my uninformed perspective, it seems that shoving the Win32
window/display/device/whatever into wgl_display is the best approach.
But you and Jose likely know better than me. Whatever you need to do to
get it to work.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 01/10] pkg/archlinux: Update to a dual (+multilib) package
On Sat, May 31, 2014 at 03:21:59AM +0100, Emil Velikov wrote: Include both 64bit and multilib binaries when building on x86-64 platform. This saves us deeping track of version numbers and interdependencies in case of a split package. v2: Rebase and bump pkgrel Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- pkg/archlinux/waffle-1.3.0/PKGBUILD | 86 +++-- 1 file changed, 73 insertions(+), 13 deletions(-) The x86_64 package shouldn't depend on lib32 packages. Not everyone needs or wants to enable the multilib repo, and waffle shouldn't force them to do that. If you're concerned about the lib32-waffle PKGBUILD drifting out-of-sync with the base waffle PKGBUILD, maybe you could cleverly use the bash 'source' directive and string substitution. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 02/10] cmake: reformat/update install targets
On Sat, May 31, 2014 at 03:22:00AM +0100, Emil Velikov wrote: Cleanup the formatting and add component for each build target. The latter will allow us to use CPack to create a component based installer for Windows. Additionally install wflinfo to CMAKE_INSTALL_BINDIR rather than hardcoding it to 'bin'. v2: Tag html documentation as htmldocs COMPONENT. Suggested by Chad. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 04/10] cmake: add autodetection for waffle_has_egl, glx...
On Sat, May 31, 2014 at 03:22:02AM +0100, Emil Velikov wrote: Silence the pkg_check_modules and check set the default options depending on the packages found. This is a good idea and will make Waffle easier to configure for everyone. There are a few problems though. If configuration fails because the user tried to enable a platform for which his system lacks the dependencies, then post-patch CMake no longer gives sufficient explanation why it failed. For example, if -Dwaffle_has_gbm=1 fails, CMake informs the user thta gbm requirements are not met but does explain what those requirements are. And, since waffle_pkg_config is now silenced by QUIET, CMake's earlier output provides no clue. To avoid providing the user a silent mystery, this block +if(waffle_has_wayland) +if(NOT wayland-client_FOUND OR + NOT wayland-egl_FOUND OR NOT egl_FOUND) +message(FATAL_ERROR wayland requirements are not met.) +endif() +endif() should explain which requirements, including the version if any, were not met. For example, if -Dwaffle_has_wayland=1 but the system lacks wayland-egl=9.1, then CMake should print something like wayland dependency is missing: wayland-egl=9.1 or wayland requirement wayland-egl=9.1 is not met Why did you decide to silece waffle_pkg_config with QUIET? I feel that it's useful to get notification for each item that CMake probes for. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 05/10] waffle: remove found_platform from waffle_init_parse_attrib_list
On Sat, May 31, 2014 at 03:22:03AM +0100, Emil Velikov wrote:
Whenever a platform is missing a case statement, the default will
kick in throwing an error and exiting the function.
Ah, but that's not what 'found_platform' is checking for...
-if (!found_platform) {
-wcore_errorf(WAFFLE_ERROR_BAD_ATTRIBUTE,
- attribute list is missing WAFFLE_PLATFORM);
-return false;
-}
... waffle_init() uses 'found_platform' to check if the user provided
WAFFLE_PLATFORM.
I admit that waffle_init_parse_attrib_list() is a clumsily written
function. It was one of the very first functions in Waffle's codebase.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 08/10] cgl: avoid leaking the PixelFormat
On Sat, May 31, 2014 at 03:22:06AM +0100, Emil Velikov wrote: According to apple developer page, starting with OS X v10.5 the pixelformat is reference counted. The object is created at CGLChoosePixelFormat and should be unrefeferenced via CGLReleasePixelFormat/CGLDestroyPixelFormat. The latter two are identical accoring to the documentation. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/waffle/cgl/cgl_config.m | 4 1 file changed, 4 insertions(+) All CGL patches in this series look good to me. However, I'll defer committing them until I've tested them on my MacBook. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 09/10] x11: correctly set the screen number of the current display
On Sat, May 31, 2014 at 03:22:07AM +0100, Emil Velikov wrote: Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/waffle/x11/x11_display.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/waffle/x11/x11_display.c b/src/waffle/x11/x11_display.c index 43b6ef0..8a3524d 100644 --- a/src/waffle/x11/x11_display.c +++ b/src/waffle/x11/x11_display.c @@ -48,8 +48,7 @@ x11_display_init(struct x11_display *self, const char *name) return false; } -// FIXME: Don't assume screen is 0. -self-screen = 0; +self-screen = DefaultScreen(self-xlib); return true; } Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 10/10] glx: glx_context_create_native returns GLXContext not bool
On Sat, May 31, 2014 at 03:22:08AM +0100, Emil Velikov wrote: Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/waffle/glx/glx_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/waffle/glx/glx_context.c b/src/waffle/glx/glx_context.c index c7a7d91..62573dc 100644 --- a/src/waffle/glx/glx_context.c +++ b/src/waffle/glx/glx_context.c @@ -167,7 +167,7 @@ glx_context_create_native(struct glx_config *config, ok = glx_context_fill_attrib_list(config, attrib_list); if (!ok) -return false; +return NULL; ctx = wrapped_glXCreateContextAttribsARB(platform, dpy-x11.xlib, -- Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/3] Memory leak fixes
On Sun, Jun 01, 2014 at 03:11:59PM +0100, Emil Velikov wrote: Spotted while searching for a severe memory corruption under wgl. Did not manage to find it yet, although notices these bad boys. Awesome. Patch 1 is rb'd and committed to master. I will case the corruption bug over the next few days + cleanupsplit the patches hopefully I will see what's going wrong, or perhaps someone will be kind enough to point out what I'm doing wrong :) AFAICS the user is supposed to explicitly release the current context using waffle_make_current(dry, NULL, NULL), is that correct ? I'll get back to you on that question tomorrow. I don't trust my judgement this late into the night ;) ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [GSOC2014] Current design/implementation + the infamous corruption
On Thu, Jun 05, 2014 at 05:49:04PM +0100, Emil Velikov wrote:
On 05/06/14 03:19, Emil Velikov wrote:
waffle_window_create(config, w, h)
+ waffle_window_resize() // Reuse the window... and boom. Any suggestions on
// how to resolve this, or should we mandate that
// this is not a valid usage of waffle ?
There is no use case in piglit + waffle{examples/utils} where one would create
multiple windows for a single config. I might just add a lovely assert and
don't worry about this too much.
Don't worry too much about getting mutliple windows to work. Last
I checked, multiple window support was broken in the Android backend
too. It's perfectly ok to aim for imperfect good-enough during Waffle's
initial Windows support.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCHv2 04/10] cmake: add autodetection for waffle_has_egl, glx...
On Fri, Jun 06, 2014 at 02:18:37PM +0100, Emil Velikov wrote: Silence the pkg_check_modules and check set the default options depending on the packages found. Error out if the user has selected an option and it's requirements are not met. v2: - Do not silence pkg_check_modules. - Explicitly list the failing requirements. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- The patch turned out a bit longer that I would like to, although I cannot see any sane way of splitting it up :'( At least it nicely prints which dependency is missing, so that there should be little-to-no head-bashing from people building waffle. I'm also unhappy how verbose the patch is, but I don't see a way to shorten it either. Unless we go the way of macro madness. Thanks for adding messages that will help the unlucky user. It's committed to master. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 05/10] waffle: remove found_platform from waffle_init_parse_attrib_list
On Fri, Jun 06, 2014 at 12:24:06PM +0100, Emil Velikov wrote:
On 06/06/14 07:25, Chad Versace wrote:
On Sat, May 31, 2014 at 03:22:03AM +0100, Emil Velikov wrote:
Whenever a platform is missing a case statement, the default will
kick in throwing an error and exiting the function.
Ah, but that's not what 'found_platform' is checking for...
-if (!found_platform) {
-wcore_errorf(WAFFLE_ERROR_BAD_ATTRIBUTE,
- attribute list is missing WAFFLE_PLATFORM);
-return false;
-}
... waffle_init() uses 'found_platform' to check if the user provided
WAFFLE_PLATFORM.
AFAICS that is handled by the default switch case.
I admit that waffle_init_parse_attrib_list() is a clumsily written
function. It was one of the very first functions in Waffle's codebase.
IMHO the code bails out if we've missed (partially or fully) any platform
and/or if the user has provided a invalid WAFFLE_PLATFORM. Thus we will reach
the if (!found_platform)... only when the variable is already set (via the
CASE_DEFINED_PLATFORM macro).
Perhaps this code is targeting some elaborate use-case which I'm failing to
see here?
I think you're failing to see the use-case because it's extremely
*unelaborate*.
This block...
if (!found_platform) {
wcore_errorf(WAFFLE_ERROR_BAD_ATTRIBUTE,
attribute list is missing WAFFLE_PLATFORM);
return false;
}
... catches the case when the user supplies *no* attribute. That is, it
catches these three erroneous cases:
waffle_init(NULL);
waffle_init((int32_t[]){});
waffle_init((int32_t[]){0});
In other words, 'found_platform' detects when codeflow altogether skips
the switch statement.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Waffle and GL dispatch
On Thu, Jun 26, 2014 at 05:46:56PM +0100, Eric Anholt wrote: Emil Velikov emil.l.veli...@gmail.com writes: Not aiming at it atm, but just curious - which one would you consider as the better option: - Convert waffle to use libepoxy, or - clone the current implementation into waffle and work from there ? Make waffle link against libepoxy. I don't want to import the libepoxy code into waffle. But I'm also not fundamentally opposed to adding a written-from-scratch dispatch mechanism to waffle. But, we should avoid adding any written-from-scratch dispatch until (1) waffle's users (piglit, apitrace, maybe a few more?) really need dispatch and (2) we've made a real effort to make libepoxy work. (There does exist a waffle user, Piglit, who *does* need dispatch, and libepoxy today doesn't work for it, and I just recently rewrote large hunks of Piglit's homebrew dispatch, but I digress... I'm still waiting for libepoxy to become Piglit-friendly). As for why Eric didn't add dispatch to waffle, it's because most users just want dispatch and not the GLX/CGL/Android/EGL abstraction that waffle provides. Any realworld app, like a game, needs much more from a platform abstraction layer than what waffle provides and will ever provide, such as input and audio. Since realworld games already have chosen their own platform abstraction layer, it doesn't make sense to require them to add another platform abstraction (waffle) to be able to get sane GL dispatch. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] waffle-wgl a hefty mId-term code drop :)
On Thu, Jun 26, 2014 at 12:55:53PM +0100, Emil Velikov wrote: Hi all, It's official the first half of the project is now complete. Concise and up-to the point information can be seen in the release notes [1]. [1] https://github.com/evelikov/waffle/releases/tag/v1.0 Awesome! P.S. If it was not obvious in my earlier email asking about gl dispatch, that the next big step might be getting it in waffle in any shape or form. Dispatch is heavy on my mind this month, because I just rewrote large hunks of Piglit's dispatch. And later this year I need to port Waffle and Piglit's dispatch to Chrome NaCl. And Jordan recently raised the possiblity of adding a Waffle dispatch, maybe only as an internal-api at first, so we can add a wflgears demo. So maybe Waffle and/or Piglit need a newer better dispatch mechanism sooner than I thought. But I don't want to hijack your announcemet email ;) , so let's continue this dispatch conversation later. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/3] Memory leak fixes
On Thu, Jun 26, 2014 at 01:17:30PM +0100, Emil Velikov wrote: On 06/06/14 07:38, Chad Versace wrote: On Sun, Jun 01, 2014 at 03:11:59PM +0100, Emil Velikov wrote: Spotted while searching for a severe memory corruption under wgl. Did not manage to find it yet, although notices these bad boys. Awesome. Patch 1 is rb'd and committed to master. I will case the corruption bug over the next few days + cleanupsplit the patches hopefully I will see what's going wrong, or perhaps someone will be kind enough to point out what I'm doing wrong :) AFAICS the user is supposed to explicitly release the current context using waffle_make_current(dry, NULL, NULL), is that correct ? I'll get back to you on that question tomorrow. I don't trust my judgement this late into the night ;) Chad, would you have a few minutes when you're feeling fresh about the explicit vs implicit cleanup topic? waffle_make_current(dpy, NULL, NULL) releases no memory allocated by waffle itself, If any memory gets released, the backend call (glXMakeCurrent, eglMakeCurrent) does the releasing. Usually, eglMakeCurrent(dpy, NULL, NULL) does not release the currently bound EGLContext. It only releases the currently bound EGLContext if the context was queued for deletion by a previous call to eglDestroyContext() or eglTerminate(dpy). I expect glXMakeCurrent behaves the same, but I'm not really sure. So you're right. An EGLContext never gets truly released until you unbind it with eglMakeCurrent(dpy, NULL, NULL, NULL). In theory, according the EGL spec, it doesn't really matter if you unbind it before or after eglDestroyContext, though. EGL will destroy it all the same. However, to be safe against drivers with buggy resource tracking (ahem, like Mesa), it's probably a good idea to unbind the context before trying to destroy it. Thanks for finding the bug [and reminding me :)]. I'll commit the patches soon. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] waffle vs msvc: Round 1, Fight !!!
On Mon, Jun 30, 2014 at 01:05:27AM +0100, Emil Velikov wrote:
Hello all,
Another day another long email :)
As usual, a list of issues, possible solutions, and my personal
preference for each. At the end I have tried to assign a priority for
most.
Any input would be greatly appreciated.
Highlights:
General (nitbits):
* C Hello world does not work OOTB with VC12 :)
** Have to switch the platform toolset to v120_xp, as the default
v120 complains about missing headers, libraries... (SDKDDKVer.h...),
* Compiling ninja - fails due to the missing toolset.
** Planning to use VC for now.
Jose are you having similar experience with VC12 ? Pardon but I'm
using VC12 for the first time, and the documentation out there is
rather... :\
Build system related:
* Tests fail to build due to the missing toolset (+ others?)
Possible fix(es)
** if (windows !mingw) hardcode generator and toolset across whole
of waffle endif ()
* cmake does not find some headers and libs - GL/gl.h windows.h opengl32.lib
Possible fix(es)
** Hardcode the libname, and ignore the headers' location as they
should just work (tm)
On you GSOC2014 branch, I see that you're searching the headers with:
if(waffle_on_windows)
find_path(opengl_INCLUDE_DIR GL/gl.h REQUIRED)
...
endif()
What happens if you instead do this?
if(waffle_on_windows)
find_path(OpenGL REQUIRED)
...
endif()
POSIX only
* getopt (utils/wflinfo, examples/gl_basic) - reuse one of the
following (license implications?)
Current implementations
**
http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/pkgtools/libnbcompat/files/getopt.c
(BSD 3-clause)
**
http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/misc/getopt.c
(unknown + BSD 2-clause)
Leaning towards reusing the NetBSD's implementation.
I also prefer to reuse NetBSD's getopt. As long as VisualStudio can
compile it :/
* pthreads - reuse one of the following (license implications?)
Current implementations
** http://locklessinc.com/downloads/winpthreads.h (BSD 3-clause)
** https://www.sourceware.org/pthreads-win32/ (GNU Lesser GPL)
** http://cgit.freedesktop.org/mesa/mesa/tree/include/c11/threads_win32.h
(Boost Software License, Version 1.0)
**
http://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads
(unknown [2]) - allegedly uses undocumented Windows API's
Leaning towards reusing locklessinc's implementation.
For now, I also prefer to use a permissively licensed simulation of the pthreads
API. Ideally, using a pthreads wrapper means you could simply drop in the
winpthreads.h header and waffle's pthreads usage should just work.
If time were not a decision factor, I would also consider Mesa's
simulation of the standard C11 threads API. But that would require you
to make more changes to Waffle, and therefore take more time.
Other
* Symbols must be identically annotated in both declaration and
definition (i.e. we need to bring WAFFLEAPI back into the public
header ?)
Possible fix(es)
** Pre-parse the header and ship one without the keyword ?
** Define an empty WAFFLEAPI when using MSVC and use module
definition file (.def)
Leaning towards using a .def
I want to avoid mangling the header sources. Instead, let's use
the preprocessor to solve this problem.
I suggest examining /usr/include/KHR/khrplatform.h for possible
solutions.
* struct waffle_* {} wfl - not strictly supported by C99 ?
http://stackoverflow.com/questions/755305/empty-structure-in-c
MSVC message C requires that a struct or union has at least one member
Possible fix(es)
** Add a dummy param inside the struct. We do not rely on the struct
having a zero size but use it as a pointer to the start of the parent
struct ?
Chad, does the last point make sense or did I completely miss out the
plot while reading through the internal API ?
Ugh. I regret doing that little bit of nastiness in the internal API.
I just submitted a patch to the list, you cc'd, to fix this.
Priority (high to low)
* struct waffle_* {} wfl
* pthreads
* getopt
* WAFFLEAPI
* everything else
Cheers,
Emil
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 03/33] cgl: avoid leaking the PixelFormat
Patches 1-3 look good and are committed to master. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 05/33] api: remove double NULL check
On 07/07/2014 10:28 AM, Emil Velikov wrote: We check if the object is NULL before appending it to the obj_list and a second time as we append it. Drop the latter as it makes the code more confusing than it needs to be. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/waffle/api/waffle_context.c | 2 +- src/waffle/api/waffle_gl_misc.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 07/33] linux: plug a memory leak
On 07/07/2014 10:28 AM, Emil Velikov wrote: Chad, do you have a plan/idea how to handle this ? I'm assuming that your plan is to tackle this once waffle_init is gone/replaced with a better solution (issue #7). There appears to be a straightforward solution: add a new API call waffle_finish(void) that tears down the global state set up by waffle_init(). The caveat is that if the user makes the calls in this sequence: waffle_init(platform=any_egl_platform) ... waffle_finish() ... waffle_init(platform=a_different_egl_platform) BOOM! ...then older versions of Mesa crashes inside libEGL. I think the issue existed as recent as Mesa 10.0. Despite the danger of crashing when on buggy drivers, I think adding waffle_finish() to the API is a good idea. And as you point out, deprecation of waffle_init() will lead to a different, but orthogonal solution, to memory leaks. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 16/33] third_party/threads: import c11 threads emulation wrappers
Emil, I'm finished reviewing for today, and am stopping here at patch 16. I'll resume reviewing tomorrow. I see that you're collecting reviewed-by tags and cleanups on versioned brancehs (for-upstream-3.*). I will defer cherry-picking patches off the mailing list onto master; and instead will wait for you to send merge requests, because I assume that was your intended workflow. If you want to do things differently, let me know. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] Windows workflow and updates
On 07/21/2014 09:45 AM, Emil Velikov wrote: On 17/07/14 05:40, Chad Versace wrote: I see that you're collecting reviewed-by tags and cleanups on versioned branches (for-upstream-3.*). I will defer cherry-picking patches off the mailing list onto master; and instead will wait for you to send merge requests, because I assume that was your intended workflow. If you want to do things differently, let me know. I do not mind either way (cherry-picking or sending pull requests), I mostly work this way to have a form of an incremental build-up based on the feedback received. Since you don't mind either way, I prefer to receive pull requests for the style of work your doing: long patches series with multiple reviewers. Please send a pull request for the patches that are ready for committing. There are a lot of patches on the list, and I'm sure you have many more pending :) It would be good to merge some patches soon before too many get queued up. Changes in for-upstream-3.2: - addressed your initial comments - dropped patch 10 (add -fPIC for the whole of waffle) - updated patch 17 (introduce third_party/threads) to build with PIC - squashed two warnings in the threads library (separate commits so that I can get them back in mesa) - cleaned/simplified up the cmocka build to make it possible to make it buildable in cross-builds and/or windows A bit more work on separate branches - cleaned up a few cmocka warnings, sent the fixes upstream - not merged yet - de-duplicated the platform specific tests in gl_basic_test, having fun with porting run_testsuite() - fork(), waitpid()... to win32 - moved libEGL from link dependency to dlopen() at runtime - got bored of reading MS documents - added basic wgl support for piglit - might not be as straight forward as I expected, see below for more Brian, Jose, Short summary at my next obstacle and my current ideas/possible solutions 1) My present WGL code does not have the *.get_native() hooks. Currently beating them into shape. For now, I think the development focus should be on the core waffle functions (waffle_make_current, waffle_window_swap_buffers, waffle_context_create, ...). Let's get those functions working well (even if it requires an API break) before worrying too much about the get_native functions. I understand that, before Piglit can use Waffle on Windows, that Waffle needs to either (1) support the get_native functions on Windows or (2) provide an API for basic input. But the WGL/CGL/GLX/EGL abstraction is the more important thing. 2) AFAICS there are ways to address the input issue a) rip out the glut completely and write Windows specific code for the input handling. I have close to zero experience in this area, any suggestions ? What would happen with other platforms using glut like MacOS ? Is it even possible to do that today ? b) rip out the glut GL parts but keep the input code in. Seems slightly messy and I'm not sure it will even work. Any ideas/suggestions on point 2 above ? Good question. Input is a real problem. I regret implementing the X11 input handling in Piglit instead of Waffle. I chose to implement in Piglit solely for the sake of expediency. I had difficulty designing a basic input API for Waffle, so I just hackily put in Piglit until I arrived at a proper solution. Doing that again for every Piglit platform (Windows, Mac, Wayland) would be possible but messy. My intuition says we should put the input in Waffle, but I'm not certain yet. I'm tentatively leaning towards this solution: c) Design a very basic input API that fits Piglit's needs. Implement it in Waffle so that other testsuites and utility apps can use it. Last but not least - which approach would be the best for getting the WGL code integrated upstream ? 1) one big code blob 2) commit one - empty skeleton, two - widows_create, three - window_show... 3) keep the series as is - small and gradual changes 4) other ? I'm leaning towards the third option, yet we're talking about ~25 commits. Perhaps the second would be a reasonable compromise ? I prefer #2 or #3, whatever is easiest for you. I don't mind long patch series. I don't mind giant blob commits either, as long as the blob is self-contained. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 16/33] third_party/threads: import c11 threads emulation wrappers
On 07/23/2014 09:11 AM, Jose Fonseca wrote: On 21/07/14 17:45, Emil Velikov wrote: On 17/07/14 05:40, Chad Versace wrote: Emil, I think that mixing GLUT with other stuff is a bad idea. Otherwise -- whether to add some input support to waffle or not -- is a design choice that Chad needs to make. On one hand most similar frameworks (GLUT, GLFW) tend to have input too. One the other hand. For GL testing (piglit/apitrace) probably it doesn't make much difference either way. At least for piglit/apitrace input is not really a must: in the -auto input is ignored, and in the non -auto mode we could simply put a Sleep() function instead of a wait-for-key, which would probably be good enough for most cases. (We could also read input from stdin, which can be done with portable C) Jose, that's a genius idea: let Piglit use stdin for input. If stdin is really capable of capturing all of Piglit's input needs, I think that's the easiest path to take. I have been reluctant to add any input API to Waffle because, honestly, it would be a half-baked solution hastily designed to accommodate Piglit. If Waffle's design goals are kept focused, then it is more likely to accomplish its goals well. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] waffle-fixes
On 07/27/2014 05:38 AM, Emil Velikov wrote: Humble ping :) On 22/07/14 20:42, Emil Velikov wrote: Hi Chad, Can you please pull the series into master. It contains most of the lengthy series of fixes that was flowing on the mailing-list. Ping acknowledged :) I merged your series into branch 'next'. I didn't want to introduce any big changes in 'master' because I'm preparing to release v1.4. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 03/18] README_WIN: add some notes about configuring and building WGL
On 07/23/2014 08:40 AM, Emil Velikov wrote: On 23/07/14 16:13, Jose Fonseca wrote: On 23/07/14 04:31, Emil Velikov wrote: TODO: - Fill in the missing sections. - Move to a better place. - Double-check for typos and thinkos. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- README_WIN.txt | 157 + 1 file changed, 157 insertions(+) create mode 100644 README_WIN.txt Isn't this duplicate info? Instead of breaking things into build install and package, I'd first break things into platform, and then, internally split into build install package. Otherwise people need to jump back forth alot unnecessarily. Plus there's a lof of duplication. Indeed it does. This is a mere copy-paste from the current README. Will need to see with Chad what his plans are on the topic, as waffle currently forwards people to ./doc/building.txt which seems to be missing on my tree. Thanks for pointing out the out-of-date instructions in the README. I just pushed updated build instructions [1] to branches 'master' and 'next'. I agree with Jose here. The build instructions would be easier to follow if they were first split by platform, then split into configure/build/install. Also, let's put this info into the main README where the build instructions currently live for Linux and Mac. There's no need to ostracize the Windows instructions in a separate file like it's a second-class citizen. Being in the same file will also allow you to reference other sections of the file instead of copying them. As a side node, if you do need to add additional README files in the future, please name them README.lowercase_topic.txt or README.camelCaseTopic.txt. For example, this file would have been README.windows.txt. [1] https://github.com/waffle-gl/waffle/commit/1ed60d0639ee3d33b9c1b542b021cfaf67d24125 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 01/18] cmake: include the CPACK module
On 07/22/2014 08:31 PM, Emil Velikov wrote: Will be used to ease distribution of binary tarballs. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- CMakeLists.txt | 22 ++ 1 file changed, 22 insertions(+) Very cool. I never knew about CPack. I like this much more than the traditional GNU-style `make dist` or `make tarball`. Reviewed-by: Chad Versace chad.vers...@linux.intel.com Tested-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 02/18] pkg/archlinux: add mingw-w64-waffle package
Emil, I can't get this PKGBUILD to build. What am I doing wrong?
I'm probably doing a lot wrong, because I've never used mingw before.
I installed all the dependencies listed in the PKGBUILD. Below
is a bash log that shows the build failures.
Jose, do you use Archlinux? Did you have any luck with this PKGBUILD?
On 07/22/2014 08:31 PM, Emil Velikov wrote:
- Remove explicit build options (waffle has autodetection).
- Correct the destination directories.
- Bump mingw64-crt requirement 3.1.0-3 (fixes the strerror_s issue).
- Build twice - once for cross-builds and second time for win32 usage.
TODO:
- Get CPack to amend the install prefix - fix the build twice issue.
- Strip some/all of the binaries ?
- Current package works of a local git repo. Rename to -git or
convert to a release one ?
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
pkg/archlinux/mingw-w64-waffle/PKGBUILD | 80
+
1 file changed, 80 insertions(+)
create mode 100644 pkg/archlinux/mingw-w64-waffle/PKGBUILD
diff --git a/pkg/archlinux/mingw-w64-waffle/PKGBUILD
b/pkg/archlinux/mingw-w64-waffle/PKGBUILD
new file mode 100644
index 000..a2ebde5
--- /dev/null
+++ b/pkg/archlinux/mingw-w64-waffle/PKGBUILD
@@ -0,0 +1,80 @@
+# Maintainer: Chad Versace chad.vers...@linux.intel.com
+
+pkgname='mingw-w64-waffle'
+pkgver='1.3.0'
+pkgrel=1
+pkgdesc='a library for choosing window system and OpenGL API at runtime
(mingw-w64)'
+arch=('any')
+url='http://waffle-gl.github.io'
+license=('BSD')
+
+depends=(
+ 'mingw-w64-crt=3.1.0-3'
+ )
+makedepends=(
+ 'mingw-w64-cmake'
+
+ # For building the docs.
+# XXX: Add as soon as we enable docs/manpages
+# 'libxslt'
+# 'docbook-xsl'
+
+ )
+
+options=('!strip' '!buildflags' 'staticlibs')
+_architectures=i686-w64-mingw32 x86_64-w64-mingw32
+
+srcroot=${HOME}/development/waffle
+build() {
+ unset LDFLAGS
+ cd ${srcroot}
+ msg Building mingw-w64-waffle for cross-building
+ for _arch in ${_architectures}; do
+mkdir -p build-${_arch} pushd build-${_arch}
+${_arch}-cmake .. \
+ -DCMAKE_INSTALL_PREFIX=/usr/${_arch} \
+ -DCMAKE_INSTALL_LIBDIR=/usr/${_arch}/lib \
+ -DCMAKE_BUILD_TYPE=Release \
+ \
+ -Dwaffle_build_tests=0 \
+ -Dwaffle_build_manpages=0 \
+ -Dwaffle_build_htmldocs=0 \
+ -Dwaffle_build_examples=1
+make
+popd
+ done
+
+ # There should be a better way to do this
+ msg Building mingw-w64-waffle for native builds
+ for _arch in ${_architectures}; do
+mkdir -p build-${_arch}-win pushd build-${_arch}-win
+${_arch}-cmake .. \
+ -DCMAKE_INSTALL_PREFIX= \
+ -DCMAKE_INSTALL_LIBDIR=lib \
+ -DCMAKE_BUILD_TYPE=Release \
+ \
+ -Dwaffle_build_tests=0 \
+ -Dwaffle_build_manpages=0 \
+ -Dwaffle_build_htmldocs=0 \
+ -Dwaffle_build_examples=1
+make
+popd
+ done
+}
+
+package() {
+ for _arch in ${_architectures}; do
+cd ${srcroot}/build-${_arch}
+make DESTDIR=${pkgdir} install
+#${_arch}-strip --strip-unneeded $pkgdir/usr/${_arch}/bin/*.dll
+#${_arch}-strip -g $pkgdir/usr/${_arch}/lib/*.a
+ done
+
+ for _arch in ${_architectures}; do
+cd ${srcroot}/build-${_arch}-win
+# Create Windows zip archives
+make package
+ done
+}
+
+# vim:set ts=2 sw=2 et:
Chad's build errors
$ git checkout evelikov/for-upstream-WGL
$ git log -1 --format=%H
ed2164dfb4ae6d957ef853c054357202ba60f883
$ cd pkg/archlinux/mingw-w64-waffle
$
$ # Do a mingw sanity test. It fails :(
$ cat sanity.c
int
main() {
return 0;
}
$ /usr/bin/i686-w64-mingw32-gcc sanity.c
$ /usr/lib/gcc/i686-w64-mingw32/4.9.1/cc1: error while loading shared
libraries: libisl.so.13: cannot open shared object file: No such file or
directory
$
$ # Now build Emil's PKGBUILD
$ makepkg
== Making package: mingw-w64-waffle 1.3.0-1 (Wed Jul 30 19:57:04 PDT 2014)
== Checking runtime dependencies...
== Checking buildtime dependencies...
== Retrieving sources...
== Extracting sources...
== Starting build()...
== Building mingw-w64-waffle for cross-building
~/proj/hh/default/src/waffle/build-i686-w64-mingw32 ~/proj/hh/default/src/waffle
-- The C compiler identification is unknown
-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc
-- Check for working C compiler: /usr/bin/i686-w64-mingw32-gcc -- broken
CMake Error at /usr/share/cmake-3.0/Modules/CMakeTestCCompiler.cmake:61
(message):
The C compiler /usr/bin/i686-w64-mingw32-gcc is not able to compile a
simple test program.
It fails with the following output:
Change Dir:
/home/chadv/proj/hh/default/src/waffle/build-i686-w64-mingw32/CMakeFiles/CMakeTmp
Run Build Command:/usr/bin/make cmTryCompileExec2618447734/fast
/usr/bin/make -f CMakeFiles/cmTryCompileExec2618447734.dir/build.make
CMakeFiles/cmTryCompileExec2618447734.dir/build
make[1]: Entering directory
'/home/chadv/proj/hh
Re: [waffle] [PATCH 06/18] wgl: implement display management
On 07/23/2014 08:27 AM, Jose Fonseca wrote:
On 23/07/14 16:25, Jose Fonseca wrote:
On 23/07/14 04:31, Emil Velikov wrote:
+PIXELFORMATDESCRIPTOR pfd = {
+sizeof(PIXELFORMATDESCRIPTOR),
+1,
+PFD_SUPPORT_OPENGL |
+PFD_DRAW_TO_WINDOW |
+PFD_DOUBLEBUFFER,
+PFD_TYPE_RGBA,
+32,
+0, 0, 0, 0, 0, 0,
+0,
+0,
+0,
+0, 0, 0, 0,
+16,
+0,
+0,
+PFD_MAIN_PLANE,
+0,
+0, 0, 0,
It's hard to interpret this like this. memset(0) and then writing the
fiels would make the code smaller and easier to read.
I agree with Jose, this is hard to read. Initialization of named members would
be better.
As an alternative to memset(0), you can zero-fill the struct at the declaration
site with
the syntax below, eliminating a line of code and a function call. This is
available in ANSI C,
no C99 or GNU required.
PIXELFORMATDESCRIPTOR pfd = {0};
The initialization behavior for structs on the stack is this: if the braces
specify the
initialization of any member, then all unspecified members are initialized to 0.
Here's the relevant language from the ANSI C Standard, Section 3.5.7
Initialization:
If there are fewer initializers in a list than there are members of
an aggregate, the remainder of the aggregate shall be initialized
implicitly the same as objects that have static storage duration.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/4] wgl: strings.h does not exist in MSVC
For this 4 patch series, Reviewed-by: Chad Versace chad.vers...@linux.intel.com I'll wait for a pull request. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/8] make check cleanup windows support
On 08/04/2014 07:34 AM, Emil Velikov wrote:
So it seems like I've completely missed out to send this series last
week, so here it goes.
The series covers
- Consolidates the duplicating gl_basic_test(s) into two
groups - all and all_but_cgl (as cgl is the wierd one this time).
- Adds (slightly buggy) implementation for fork() that we use on
POSIX platforms.
- Redoes a few cmake wows so that make check/check-func works for
Windows.
The series is based on top of branch for-upstream-3.2-uncommitted-fixes
which as the name suggests is are (reviewed but) uncommitted fixes, which
Jose and Chad requested to have/land after WGL is in.
This series is also available in the for-upstream-make-check-rework
branch at my github repo.
Please review,
-Emil
Hi Emil. It's good to see so much duplication removed. The series needs
a little fix, though, because now most of the tests have the same name
in the test output!
For example, here's a snippet of `make check-func`.
test: skip: gl_basic.all_but_cgl_gles10
test: skip: gl_basic.all_but_cgl_gles11
test: pass: gl_basic.all_but_cgl_gles2_rgb
test: pass: gl_basic.all_but_cgl_gles2_rgba
...
test: pass: gl_basic.all_but_cgl_gles10
test: pass: gl_basic.all_but_cgl_gles11
test: pass: gl_basic.all_but_cgl_gles2_rgb
test: pass: gl_basic.all_but_cgl_gles2_rgba
The top block comes from GLX and the bottom block from Wayland. But it's
hard to tell because of the testname collisions.
I see an easy way to fix this. I'm sure there are more I haven't thought of.
In gl_basic_test.c, defining test functions as below should work:
TEST(gl_basic, glx_gles10) { test_all_bug_cgl_gles10(); }
TEST(gl_basic, glx_gles11) { test_all_bug_cgl_gles11(); }
TEST(gl_basic, glx_gles2_rgb) { test_all_bug_cgl_gles2_rgb(); }
TEST(gl_basic, glx_gles2_rgba) { test_all_bug_cgl_gles2_rgba(); }
// Repeat for wayland, etc.
It does introduce some redundancy, but at least it's compact. Perhaps
there is a more clever way to do this.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 0/8] make check cleanup windows support
On 08/20/2014 05:58 AM, Emil Velikov wrote: On 20/08/14 00:38, Chad Versace wrote: On 08/04/2014 07:34 AM, Emil Velikov wrote: TEST_RUN2(gl_basic, glx_gl20, all_gl20); TEST_RUN2(gl_basic, glx_gl21, all_gl21); Note that this still gives us a ton of duplication, yet I feel that any further cleanups can be made at a later point :) I have pushed the TEST_RUN2 approach in branch 'for-upstream-make-check-rework-1.3' and have tested it under Linux. Let me know if you like the approach and it I should recent the massive mechanical changes to the ML. I like the TEST_RUN2 approach. It avoids some of the duplication in my proposed solution. I found one error in the series. Commit df9027a024d5bcdce1b27d608a2986ebf0e089e8, which refactors the gles tests, has a copy-paste error. It assigns wayland names to some x11_egl tests. Also, the cmake commit 3d5c7fd2e2181c3ab88a30ec376a7fd6ff487eee has some garbled text. +# Ensure that the executable is in the same folder as the library it's linke ^linked +# against. Otherwise Windows will fail to load the DLL, and the test will fa fail. With the copy-paste error and the typos fixed, the whole series is Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] x11: fix for a non-zero default screen
On 08/20/2014 07:11 AM, Emil Velikov wrote: On 19/08/14 23:10, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com Marek you have my vote if you ever run for a president, going through mesa and waffle to fix this - you're a star :) Must admit that I don't have much experience with xcb but the patch looks straightforward enough. Reviewed-by: Emil Velikov emil.l.veli...@gmail.com I echo Emil. Marek for prez because he's not afraid of screen != 0. In my make-believe world, screen is always 0 :/ Thanks. Committed to master. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 4/4] wgl: attempt to fix the final test
On 08/19/2014 11:42 AM, Jose Fonseca wrote: On 19/08/14 18:44, Emil Velikov wrote: On 19 August 2014 16:51, Jose Fonseca jfons...@vmware.com wrote: On 19/08/14 16:41, Jose Fonseca wrote: I'm sure it overflows on Linux too. valgrind might complain. But MSVC emits code to check for stack overflow -- some sort of canary. There is no crash per se -- but an error dialog. To catch bugs like this, maybe it's time that waffle gets a `make check-valgrind`. Or maybe build with -fstack-protector by default. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Final (GSoCwise) waffle WGL release
On 08/20/2014 06:55 AM, Emil Velikov wrote: waffle works like a champ with WGL, even piglit approves :P With branches 'yet-another-round-of-msvc-fixes-1.2' [1] and 'waffle-WGL-1.2' I can run piglit+waffle+wgl on my Windows 7 machine and even crash the drivers on a non-concurrent run :) Below is a summary of my piglit run. [15023/15023] crash: 24, fail: 1401, pass: 8323, skip: 5274, warn: 1 Woo! I neglected to observe that you've spammed the Piglit list too :) I will take a look at it. There are still some small bits that needs picking (one of which is the final API/ABI change which I'm trying to convince Chad is a good idea), but those will happen in due time. Meanwhile head over to the github release page [3] if you like to give it a try. Emil, start sending pull requests! Except for the one patch we're still arguing about... ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] Waffle 1.4.0-rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Waffle 1.4.0-rc1 is now released and available for testing. This is a testing preview of the upcoming 1.4.0 feature release. It's been a loong time since the last release (Waffle 1.3.0 happened in 2013!) and a lot has happened since then. Waffle now has a wflinfo utility, supports Linux DRM render nodes through the GBM backend, is packaged by several distributions, and has a proper issue tracker on Github. The most prominent change, in my opinion, as that Waffle has more active contributors than last year (namely Jordan and Emil). Since I've been out of practice of making releases, the release candidate will cautiously bake for a full week before the final release. If all goes smoothly, I plan to publish the final 1.4.0 tarballs on Monday 15 September. The next major release (2.0) will likely happen near the end of September this month. Emil has been working hard to add Windows support to Waffle and Piglit, and that needs to be packaged up and shipped soon. Tarballs and other release files are available at Release Page: http://www.waffle-gl.org/release.html#1.4.0-rc1 Source: http://www.waffle-gl.org/files/release/waffle-1.4.0-rc1/waffle-1.4.0-rc1.tar.xz GPG Signature: http://www.waffle-gl.org/files/release/waffle-1.4.0-rc1/waffle-1.4.0-rc1.tar.asc SHA256 83c62329751bf96159934d8eb062d9cc8230895e268ae6c5fb94ac00d3508af4 waffle-1.4.0-rc1.tar.xz The signed git tag v1.4.0-rc1 is available in git://github.com/waffle-gl/waffle http://github.com/waffle-gl/waffle You can verify the release files by: Verifying the tarball's signature: unxz waffle-1.4.0-rc1.tar.xz gpg --verify waffle-1.4.0-rc1.tar.asc Verifying the tag's signature: git fetch --tags origin git tag --verify v1.4.0-rc1 Verifying the tarball's checksum (least secure method): echo '83c62329751bf96159934d8eb062d9cc8230895e268ae6c5fb94ac00d3508af4 waffle-1.4.0-rc1.tar.xz' | sha256sum -c Please file bugs and issues at https://github.com/waffle-gl/waffle/issues You can view the commit history for this release at https://github.com/waffle-gl/waffle/commits/refs/tags/v1.4.0-rc1 You can track the release status of the final 1.4.0 release in Waffle's snazzy new Github tracker: https://github.com/waffle-gl/waffle/milestones Waffle 1.4.0 Release Notes (draft) == Backwards compatibility notes - - Waffle 1.4.0 is backwards-compatible with Waffle 1.3.0, in ABI and API. New Features - * All platforms * wflinfo The new 'wflinfo' utility reports information about the system's OpenGL capabilities, similar to 'glxinfo'. See the documentation at [man:wflinfo.1] or [http://www.waffle-gl.org/man/wflinfo.1.html]. (Implemented by Jordan Justen. Chad Versace fixed some bugs and corner cases). * Linux * GBM backend gains support for DRM render nodes. Waffle's GBM backend will now use render nodes (/dev/dri/render*) if available. Otherwise, it falls back to 1.3.0 behavior and will use a DRI card device (/dev/dri/card*). Render nodes require a recent kernel; you may need to add drm.rnodes=1 to the kernel cmdline. (Implemented by Jordan Justen). * Debian packaging support. Waffle now contains a toplevel 'debian' directory that supports creation of Debian packages. Waffle packages are already available in Debian Unstable (sid) as 'libwaffle-1.0', 'libwaffle-dev', 'libwaffle-doc', and 'waffle-utils'. (Debian packages are maintained by Jordan Justen). -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJUDN2rAAoJEAIvNt057x8ihv0P/01+v0dMGzp1nBeLHode9Mc7 +THUOS7HGA1W0N6FpPGxkiOj4q+19A8QRSp/jyIot6YV4xev3Sby9NTt/vSQO21w MM8KNtXpFogim9M7EBn+iaCK6rn1vNLWWIOpdtgfRRJUky6NHNshYRSsfQUzT4hg sjfjZT8y3mRoswUAIUaXLcnm9Weng+o48zmMI/IC0NB0eFhmziswYv+eSuVbC5z6 xFJoiOsgLAOhfr1fxAk5xuDOpSKavnl/MVGYgnlUUcFQ7mzFaCtTnW/BINgvt9CC bUsy05wp5MFxNfWaNGeE8i6t69J1mc1WuIyaPk0jAzLGh6oMmX/E0hbyx/Xl5Qjr Mj4ApqbmWmpM8HPiJ2I6pE2x5iyVf2Tsj12kD6IDQyQ+bYAwj2lYxdzgPHQPhVXq rhrCTee0faV+KtYNpAH3Eadn1LLDRZnMgTCgKlRx6YYP9a6P4Wiym8vlwC3RShT4 /pEfLn4QDJ6fRNv7Pj/gjhFfEL5y4lboWFnHXegmZneWrSrTcPLEDwRTPX03UJ2u TUVpKHiy5oeqDWytE89uTjltwedem57h/3DsQ93NZAcF8Wi+kRi8BqsIQf2UIipm eVEmrmGzMTc0hhEY65YR016t7iMltuAVu9oeJLQcIxys0qZQv/yJX2Kytqttc013 BLU+8Ype9jC58XKtWBNN =WQHb -END PGP SIGNATURE- ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] cmake: wire up check and check-func with valgrind
On 09/10/2014 05:23 AM, Emil Velikov wrote:
On 10/09/14 01:38, Emil Velikov wrote:
Add a valgrind-* counterpart for each target. Note that the
valgrind-check-func seems to leak like a sleeve yet I'm
suspecting that part of it is due to cmocka :P
Small update:
Thanks to Nils Gladitz we can drop the hard-coded paths by using a generator
expression like below
+COMMAND ${VALGRIND_EXECUTABLE}
${CMAKE_BINARY_DIR}/tests/${unittest_name}
COMMAND ${VALGRIND_EXECUTABLE} $TARGET_FILE:${unittest_name}
+COMMAND ${VALGRIND_EXECUTABLE}
${CMAKE_BINARY_DIR}/tests/functional/gl_basic_test
COMMAND ${VALGRIND_EXECUTABLE} $TARGET_FILE:gl_basic_test
Without or without Nils' changes, this patch is
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
I've already applied Nil's changes in my local branch. Do you mind
if I push with his changes added?
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Checking In
On Wed 22 Oct 2014, Emil Velikov wrote: On 11/09/14 15:43, Chad Versace wrote: On 09/07/2014 05:37 PM, Jordan Justen wrote: Having a year between 1.3 and 1.4, I'm reluctant to introduce delays. To avoid delays like that in the future, I'm thinking that waffle should adopt a short, time-based release cycle. Maybe every 4 to 6 weeks. With a cycle that short... 1. There would be no pressure to delays a release for a feature. Because a new release is right around the corner. 2. If there's nothing interesting to release for a given cycle, then we could just skip doing that release. 3. The release process would, by necessity of frequency, become mostly automated. That automation would allow anyone (not just me) to do a release. I haven't *decided* on any of the above. Just thinking that it may be a good idea. What do you think? All of those sounds ok with me, yet I hope that the level of automation is better than the one we have in mesa. I began writing a python script to fully automate that process. The script builds waffle, runs its testsuite, makes a git tag, creates a tarball and signs it, uploads everything, and then writes out a template announcement email. I should dig that script up, clean it up, and commit to the repo. So... let's try not to delay 2.0. And let's make releases more frequent. Then Emil's work on issue #9 will land quickly enough. Afaict one of your concerns may be bumping the library major version due to the waffle_get_proc_address API change. Admittedly I have not checked if piglit and the wfl utils will work if we leave the interface as is and I'm planning to do so tomorrow. If possible I'll avoid the API change, otherwise I might consider adding another entry point in order to preserve backwards compatibility - ie. waffle_get_proc_address2(). Either one of those will get is in waffle-1.5 land which does not sound as scary :P I would like to avoid breaking ABI compatibility unless the alternatives are really really bad. Because breaking ABI compatibility, being really^3 bad, is even worse than really^2 bad. I discussed introducing waffle_get_proc_address2() with Jordan in person, and (if I recall correctly), he was ok with the idea. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] Waffle 1.4.1
Waffle 1.4.1 is now available. This is a maintenance release that fixes bugs in 1.4.0. Tarballs and other release files are posted at: Release Page: http://www.waffle-gl.org/release.html#1.4.1 Source: http://www.waffle-gl.org/files/release/waffle-1.4.1/waffle-1.4.1.tar.xz GPG Signature: http://www.waffle-gl.org/files/release/waffle-1.4.1/waffle-1.4.1.tar.asc SHA-256 Sums: http://www.waffle-gl.org/files/release/waffle-1.4.1/waffle-1.4.1.sha256sums Release Notes: http://www.waffle-gl.org/files/release/waffle-1.4.1/waffle-1.4.1-release-notes.txt The SHA-256 checksums are: 7764f726957728f6f158c0b5c719f5fd76d4dcd0029ce3a0161a2412f10caf47 waffle-1.4.1-release-notes.txt ec3b88052e403d6eca906881394addeda7e9b625fa9192ddef7e343317180d4a waffle-1.4.1.tar.asc 66b3240b94abc30cd18c644ffc145024ad60e5b8a8a7d1e718c265b4c24351c9 waffle-1.4.1.tar.xz The signed git tag v1.4.1 is found in: git://github.com/waffle-gl/waffle Methods to verify the release files are: Verifying the tarball's signature: xz -d waffle-1.4.0.tar.xz gpg --verify waffle-1.4.0.tar.asc Verifying the tag's signature: git fetch --tags origin git tag --verify v1.4.0 Verifying the tarball's checksum: echo '66b3240b94abc30cd18c644ffc145024ad60e5b8a8a7d1e718c265b4c24351c9 waffle-1.4.1.tar.xz' | sha256sum -c Please file bugs and issues at: https://github.com/waffle-gl/waffle/issues Waffle 1.4.1 Release Notes == Bugfixes * Update the CMake requirement to 2.8.11. Changes --- Chad Versace (3): waffle: Bump version to 1.4.1 .gitignore: Ignore static libraries *.a Android.mk: Fix version of 1.4.0 Emil Velikov (1): cmake: bump minimum cmake requirement to 2.8.11 .gitignore | 1 + Android.mk | 2 +- CMakeLists.txt | 2 +- cmake/Modules/WaffleDefineVersion.cmake | 2 +- 4 files changed, 4 insertions(+), 3 deletions(-) pgp6OlERomoWe.pgp Description: PGP signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Drop the libEGL linking, take 2
On Wed 10 Sep 2014, Emil Velikov wrote: Changes comparing to previous round - raised the severity on dlopen/dlsym - crushed some typos - use the versioned lib on linux and the unversioned on android - updated the android build (but untested) Emil, this looks good to me. It's nice to see one more static dependency be removed from Waffle. I merged your series to the 'next' branch. I'll merge it to 'master' after I've had a chance to use it for several Piglit runs. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Drop the libEGL linking, take 2
On Sat 08 Nov 2014, Emil Velikov wrote: On 08/11/14 05:18, Chad Versace wrote: On Wed 10 Sep 2014, Emil Velikov wrote: Changes comparing to previous round - raised the severity on dlopen/dlsym - crushed some typos - use the versioned lib on linux and the unversioned on android - updated the android build (but untested) Emil, this looks good to me. It's nice to see one more static dependency be removed from Waffle. I merged your series to the 'next' branch. I'll merge it to 'master' after I've had a chance to use it for several Piglit runs. Great. Thanks Chad. Meanwhile I've had a quick look at libgbm and libGL. Should be doable with a lot less extra code :) Great. But before that can you let me know a branch on top of which I can respin the whole wgl support (+ extra ~30 patches after it). [...] We are both thinking about the same thing today. Just a minute ago (before reading your message), I tried rebasing onto master myself. Could you take a look and see if my rebase looks good? It's branch 'cooking/evelikov/wgl' in my personal Waffle repo [git://github.com/chadversary/waffle]. [...] The current merging of branches is making my head spin. Afaict there are some patches in master that are not present in next and vice-versa. Also hot on my mind. Earlier this morning I began making notes on the git workflow I'm trying out, with the intention of commiting to 'doc/git-workflow.txt' soon (or some file named similarly). I discovered that I have difficulty keeping track of what's what and what's been committed when all commits get commited directly to master with linear history, subversion style. So I decided recently, as an experiment, to try the workflow documented in Git's official docs as the recommended workflow, man:gitworkflow(7). Like I said, I'll soon document the exact workflow and commit it to the repo. (I'd like to say more about that, but I'm meeting someone for lunch in 3 minutes). I'll prep a cover letter for the rebase, so that you can just check with a patch or two rather than the whole series :) If you don't like the rebase I did, or you just have an itch to do it yourself (it's your patches, after all), then please rebase the series onto master. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
On Sun 09 Nov 2014, Emil Velikov wrote: As mentioned earlier here is a rebase of all the wgl work so far on top of origin/master. Merged to next! So... what does that mean??? That means I'll merge your branch to 'master' after it cooks for a little while and I'm certain Piglit doesn't complain. To answer your branching query from Saturday... Here's a *very tiny* summary of the workflow I'm following in man:gitworkflow(7). - The 'master' branch should always be stable. At any time, it should be safe to cut a release off of master. - The 'next' branch is an integration branch. That's where the interesting action happens. - Topic branches are usually first merged to 'next', unless they are obvious fixes. After baking on 'next' for enough time to reveal any lurking bugs, the same topic branch is then merged to 'master'. - As explained in man:gitworkflow(7), merges between branches always flow upwards and never downwards. That is, maint - master - next and never master - next - Merges are preferred over cherry-picks. As explained in man:gitworkflow(7): Merges have many advantages, so we try to solve as many problems as possible with merges alone. Cherry-picking is still occasionally useful. Most importantly, merging works at the branch level, while cherry-picking works at the commit level. [...] Merges are also easier to understand because merge commit is a promise that all changes from all its parents are now included. There is a tradeoff of course: merges require a more careful branch management. [...] Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards into each other. [A merging upwards strategy] gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
On Mon 10 Nov 2014, Emil Velikov wrote: On 10/11/14 06:17, Chad Versace wrote: On Sun 09 Nov 2014, Emil Velikov wrote: - As explained in man:gitworkflow(7), merges between branches always flow upwards and never downwards. That is, maint - master - next and never master - next - Merges are preferred over cherry-picks. As explained in man:gitworkflow(7): Merges have many advantages, so we try to solve as many problems as possible with merges alone. Cherry-picking is still occasionally useful. Most importantly, merging works at the branch level, while cherry-picking works at the commit level. [...] Merges are also easier to understand because merge commit is a promise that all changes from all its parents are now included. There is a tradeoff of course: merges require a more careful branch management. [...] Always commit your fixes to the oldest supported branch that require them. Then (periodically) merge the integration branches upwards intoeach other. [A merging upwards strategy] gives a very controlled flow of fixes. If you notice that you have applied a fix to e.g. master that is also required in maint, you will need to cherry-pick it (using git-cherry-pick(1)) downwards. This will happen a few times and is nothing to worry about unless you do it very frequently. Fwiw although it somewhat makes sense to merge maint into master, I'm personally commit to master and cherry-pick to stable/maint kind of person. Either way, as long as you're ok dealing with conflicts etc. I'll deal with it :P I like the merge conflicts. They make me feel safer, more aware of the global picture. Maybe I'm a masochist :/ Friendly request - please don't cherry-pick from next onto master. Agreed. If had cherry-picked from next onto master in the past, I consider that a mistake. That shouldn't happen again. ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 1/7] pkg/archlinux: use configure autodetection
On Mon 10 Nov 2014, Emil Velikov wrote: Since waffle 1.4 we have autodetection at configure time. Let's use it and drop a couple of lines PKGBUILD magic. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Patch 1 is Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 2/7] pkg/archlinux: waffle does not link against libegl
On Mon 10 Nov 2014, Emil Velikov wrote:
As such demote libegl to makedepend/optdepent, so that
one can build waffle, and optionally use x11_egl/gbm/wayland.
Patch 2 is
Reviewed-by: Chad Versace chad.vers...@linux.intel.com
And, I see for *more* EGL dependency removal. If I understand correctly,
at buildtime Waffle uses only the EGL headers, which we could easily
import into git. That would remove even libEGL from the build
dependencies, which might be overzealous but looks tempting.
pkg/archlinux/waffle-git/PKGBUILD | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/pkg/archlinux/waffle-git/PKGBUILD
b/pkg/archlinux/waffle-git/PKGBUILD
index e4a86d8..7dea3a1 100644
--- a/pkg/archlinux/waffle-git/PKGBUILD
+++ b/pkg/archlinux/waffle-git/PKGBUILD
@@ -12,7 +12,6 @@ provides=(waffle)
conflicts=(waffle)
depends=(
'libgl' # for glx
- 'libegl'
'libgbm'
'libx11'
'libxcb'
@@ -22,6 +21,8 @@ makedepends=(
'cmake'
'xcb-proto'
+ 'libegl'
+
# for building the docs.
'libxslt'
'docbook-xsl'
@@ -50,6 +51,8 @@ build() {
}
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH 3/7] gbm: fetch the libgbm function pointers at wgbm_platform_init
On Mon 10 Nov 2014, Emil Velikov wrote: Thus way with a follow up commit we can use them and eliminate the link dependency from waffle. Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/waffle/gbm/wgbm_platform.c | 43 +- src/waffle/gbm/wgbm_platform.h | 17 + 2 files changed, 59 insertions(+), 1 deletion(-) Patch 3 is Reviewed-by: Chad Versace chad.vers...@linux.intel.com ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] Remove libgbm/libGL linktime dependency
Emil, please collect my reviewed-bys onto your branch and look over the changes in my v2 of patch 4. If all looks good to you, let me know and I'll merge branch. On Mon 10 Nov 2014, Emil Velikov wrote: Hello all, As the name suggests, the series removes the hard dependency of waffle of the two libraries. Note, due to the lack of link against libGL or libEGL in the final waffle, currently gbm will FAIL yet that is a mesa issue, which ought to be resolved by the time next waffle is released. Alternatively we'll use a hack as suggested by Frank. The series can be found in branch for-chad/remove-libgbm-libgl-libdeps over at github. Cheers, Emil ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PULL] WGL support
On Wed 12 Nov 2014, Jose Fonseca wrote: Hi Emil, I went through the new patches and they look good AFAICT. Thanks for doing this. While going through wgl: fully support ARB_create_context and EXT_create_context_es_profile. again I noticed a couple of issues with the usage of WGL_EXT_create_context_es2_profile that I hadn't noticed before because I wasn't familiar with the extension: - WGL_EXT_create_context_es_profile ignored the opengl version, but WGL_EXT_create_context_es2_profile will create any version requested in. - I believe one must set WGL_CONTEXT_MAJOR_VERSION_ARB/WGL_CONTEXT_MINOR_VERSION_ARB when requesting ES contexts or one will always get a ES 1.0 context. - It's OK to assume that WGL_EXT_create_context_es2_profile then WGL_EXT_create_context_es_profile is supported, but not the other way around. This is because WGL_EXT_create_context_es_profile ignored the version See Revision History at the bottom of https://www.opengl.org/registry/specs/EXT/wgl_create_context_es2_profile.txt for details. Anyway, this is nor urgent -- it can be fixed in a follow on patch. Jose, thanks for spotting this bug. It also affects Waffle's GLX backend. So we don't forget about the bugs, I created two tickets: for WGL: https://github.com/waffle-gl/waffle/issues/23 for GLX: https://github.com/waffle-gl/waffle/issues/24 ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [RFC] Add display support to GBM backend
Frank sent this patch as a proof-of-concept. It's a draft, and not
ready for committing. I'm posting to the list just to start discussion.
See [https://github.com/waffle-gl/waffle/issues/18]. I think detailed
patch discussions like this are easier over email than Github's issue
tracker, so let's keep the bulk of the discussion in email.
Frank, I haven't examined every detail in this patch. I focused on the
high-level design. I'll probably wait to examine the fine details until
you submit a real patch for upstreaming.
From: Frank Henigman fjhenig...@chromium.org
Date: Tue, 21 Oct 2014 22:58:45 -0400
Subject: [PATCH] gbm WIP: show gbm buffers on screen
Four options based on the value of environment variable MODE:
COPY: copy render buffer to scanout buffer and flip to scanout buffer
FLIP: scan out directly from render buffer
ORIG: do what the code originally did, i.e. nothing
unset or empty: don't display, but still lock and release buffer
TO DO
- make it a compile time option
- make it a proper run time option, via config attributes or something,
instead of by env var
I prefer to make the display-mode a runtime option via attributes to
waffle_window. Perhaps we should define a new function:
struct waffle_window*
waffle_window_create_attrs(struct waffle_config *config,
const intptr_t attrib_list[]);
- leave hooks and graceful fails for (as yet) unsupported drm drivers,
currently only i915 is supported
If initially the only supported driver is i915, that's ok with me. We
have to start somewhere, and I don't like waiting for perfect
completeness.
- address all XXX in code
---
cmake/Modules/WaffleFindDependencies.cmake | 1 +
include/waffle/waffle_gbm.h| 1 +
src/waffle/CMakeLists.txt | 2 +
src/waffle/gbm/wgbm_display.h | 2 +
src/waffle/gbm/wgbm_platform.c | 2 +-
src/waffle/gbm/wgbm_window.c | 394 -
src/waffle/gbm/wgbm_window.h | 3 +
7 files changed, 402 insertions(+), 3 deletions(-)
diff --git a/cmake/Modules/WaffleFindDependencies.cmake
b/cmake/Modules/WaffleFindDependencies.cmake
index 9245772..a35ac8f 100644
--- a/cmake/Modules/WaffleFindDependencies.cmake
+++ b/cmake/Modules/WaffleFindDependencies.cmake
@@ -79,4 +79,5 @@ if(waffle_on_linux)
# waffle_has_gbm
waffle_pkg_config(gbm gbm)
waffle_pkg_config(libudev libudev)
+waffle_pkg_config(libdrm libdrm)
endif()
diff --git a/include/waffle/waffle_gbm.h b/include/waffle/waffle_gbm.h
index fe45343..c9e4691 100644
--- a/include/waffle/waffle_gbm.h
+++ b/include/waffle/waffle_gbm.h
@@ -41,6 +41,7 @@ struct gbm_surface;
struct waffle_gbm_display {
struct gbm_device *gbm_device;
+struct waffle_drm_display *drm_display;
EGLDisplay egl_display;
};
diff --git a/src/waffle/CMakeLists.txt b/src/waffle/CMakeLists.txt
index 0e42192..4866dfb 100644
--- a/src/waffle/CMakeLists.txt
+++ b/src/waffle/CMakeLists.txt
@@ -23,6 +23,7 @@ include_directories(
${gbm_INCLUDE_DIRS}
${gl_INCLUDE_DIRS}
${libudev_INCLUDE_DIRS}
+${libdrm_INCLUDE_DIRS}
${wayland-client_INCLUDE_DIRS}
${wayland-egl_INCLUDE_DIRS}
${x11-xcb_INCLUDE_DIRS}
@@ -58,6 +59,7 @@ if(waffle_on_linux)
list(APPEND waffle_libdeps
${gbm_LDFLAGS}
${libudev_LDFLAGS}
+${libdrm_LDFLAGS}
)
endif()
endif()
diff --git a/src/waffle/gbm/wgbm_display.h b/src/waffle/gbm/wgbm_display.h
index ba4bb89..59d295a 100644
--- a/src/waffle/gbm/wgbm_display.h
+++ b/src/waffle/gbm/wgbm_display.h
@@ -34,10 +34,12 @@
struct wcore_platform;
struct gbm_device;
+struct drm_display;
struct wgbm_display {
struct gbm_device *gbm_device;
struct wegl_display wegl;
+struct drm_display *drm_display;
};
static inline struct wgbm_display*
diff --git a/src/waffle/gbm/wgbm_platform.c b/src/waffle/gbm/wgbm_platform.c
index 5624660..d556145 100644
--- a/src/waffle/gbm/wgbm_platform.c
+++ b/src/waffle/gbm/wgbm_platform.c
@@ -156,7 +156,7 @@ static const struct wcore_platform_vtbl wgbm_platform_vtbl
= {
.create = wgbm_window_create,
.destroy = wgbm_window_destroy,
.show = wgbm_window_show,
-.swap_buffers = wegl_window_swap_buffers,
+.swap_buffers = wgbm_window_swap_buffers,
.get_native = wgbm_window_get_native,
},
};
diff --git a/src/waffle/gbm/wgbm_window.c b/src/waffle/gbm/wgbm_window.c
index 85378da..2a889f4 100644
--- a/src/waffle/gbm/wgbm_window.c
+++ b/src/waffle/gbm/wgbm_window.c
@@ -25,11 +25,16 @@
#define __GBM__ 1
+#include errno.h
#include stdlib.h
#include string.h
#include gbm.h
+#include xf86drm.h
+#include xf86drmMode.h
+#include i915_drm.h
+
#include waffle_gbm.h
#include wcore_error.h
@@ -72,9 +77,13 @@ wgbm_window_create(struct wcore_platform *wc_plat,
gbm_format =
Re: [waffle] [PATCH (maint-1.4)] wflinfo: Fix glGetStringi on Mali
On Thu 20 Nov 2014, Daniel Kurtz wrote:
On Thu, Nov 20, 2014 at 10:34 AM, Chad Versace chad.vers...@intel.com wrote:
diff --git a/src/utils/wflinfo.c b/src/utils/wflinfo.c
index 0b03e55..0907b4b 100644
--- a/src/utils/wflinfo.c
+++ b/src/utils/wflinfo.c
@@ -1037,7 +1037,28 @@ main(int argc, char **argv)
if (!glGetString)
error_get_gl_symbol(glGetString);
-glGetStringi = waffle_get_proc_address(glGetStringi);
+// Retrieving GL functions is tricky. When glGetStringi is supported,
here
+// are some boggling variations as of 2014-11-19:
+// - Mali drivers on EGL 1.4 expose glGetStringi statically from
+// libGLESv2 but not dynamically from eglGetProcAddress. The EGL
1.4 spec
+// permits this behavior.
In fact, AFAICT, EGL = 1.4 mandates this behavior, since glGetStringi
is an OpenGL ES 3.0 non-extension function.
I think the EGL 1.4 is ambiguous on the topic of OpenGL ES 3.0
functions. Hence the creation of EGL_KHR_get_all_proc_addresses. From
that spec:
With the addition of OpenGL and OpenGL ES 3 support to EGL, the
definition of a non-extension function becomes less clear.
And the EGL 1.4 spec, page 56, 2013-12-04, made a concession to this
ambiguity by adding footnote 21:
eglGetProcAddress may not be queried for core (non-extension) functions
in EGL or client APIs [21].
For functions that are queryable with eglGetProcAddress,
implementations may choose to also export those functions statically
from the object libraries im- plementing those functions. However,
portable clients cannot rely on this behavior.
[...]
[21] In practice, some implementations have chosen to relax this restriction.
So you're right. EGL 1.4 under one interpretation mandates Mali's
behavior. But I believe Mesa is also right under a different
interpretation allowed by the ambiguity.
Anyhow, I think we all agree that what *really* matters is that
everybody's code works, not what some vague phrase in the spec claims.
That is, unless your EGL has EGL_KHR_get_all_proc_addresses [0]:
[0]
https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_get_all_proc_addresses.txt
I just sent a patch to mesa-dev to expose this extension, with you CC'd.
+// - EGL 1.5 requires that eglGetStringi be exposed dynamically
through
+// eglGetProcAddress. Exposing statically with dlsym is optional.
EGL 1.5 essentially makes EGL_KHR_get_all_proc_addresses part of the standard.
So perhaps the check is something crazy like:
if (extension-function(function) ||
EGL =1.5 ||
(is_display_init()
EGL_has_extension(EGL_KHR_get_all_proc_addresses)) ||
(EGL_supports_client_extensions() EGL_has_client_
extension(EGL_KHR_client_get_all_proc_addresses)) {
use eglGetProcAddress(function);
} else {
use platform-specific-lookup(function);
}
Do you agree with this?
But you hide the truly crazy part! use platform-specific-lookup is
where all the fun code lives, which would contain a fairly large web of
logic.
Rather than correctly implement platform-specific-lookup today, I prefer
the below code, which non-intrusively applies to the maintenance branch:
glGetStringi = dlsym();
if (!glGetStringi) {
glGetStringi = glX/wgl/eglGetProcAddress();
}
I think the above code works for every platform.
But... couldn't we avoid this whole mess by just always using
glGetString() in wflinfo instead of jumping through hoops just to try
to use glGetStringi()?
I wish. glGetString (no i) was removed from OpenGL Core Profile. OpenGL
ES 3.0 kept the function to retain backwards compatibility with OpenGL
ES 2.0.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [RFC] Add display support to GBM backend
On 11/20/2014 12:04 PM, Emil Velikov wrote:
Hi all,
On 19/11/14 19:38, Chad Versace wrote:
Frank sent this patch as a proof-of-concept. It's a draft, and not ready
for committing. I'm posting to the list just to start discussion.
See [https://github.com/waffle-gl/waffle/issues/18]. I think detailed
patch discussions like this are easier over email than Github's issue
tracker, so let's keep the bulk of the discussion in email.
Frank, I haven't examined every detail in this patch. I focused on the
high-level design. I'll probably wait to examine the fine details until
you submit a real patch for upstreaming.
From: Frank Henigman fjhenig...@chromium.org
Date: Tue, 21 Oct 2014 22:58:45 -0400
Subject: [PATCH] gbm WIP: show gbm buffers on screen
Four options based on the value of environment variable MODE:
COPY: copy render buffer to scanout buffer and flip to scanout buffer
FLIP: scan out directly from render buffer
ORIG: do what the code originally did, i.e. nothing
unset or empty: don't display, but still lock and release buffer
TO DO
- make it a compile time option
- make it a proper run time option, via config attributes or something,
instead of by env var
I prefer to make the display-mode a runtime option via attributes to
waffle_window. Perhaps we should define a new function:
struct waffle_window*
waffle_window_create_attrs(struct waffle_config *config,
const intptr_t attrib_list[]);
That makes perfect sense, and I think we can make use of it in WGL/GLX.
Just a quick question here:
- Should the attrib list be platform specific, generic(for all
platforms) or both ?
Both might be a nice approach, this way we can have
- WAFFLE_WINDOW_FULLSCREEN
- WAFFLE_GBM_WINDOW_DISPLAY_MODE
- WAFFLE_WGL_WINDOW_HACKS
- other..
I prefer both too. That should simplify the API.
An interesting/related point here is :
How do we handle platforms where the display device is not the same as
the one doing rendering.
That will eventually become an interesting a problem to solve. But I think
it best if we defer solving it until initial support lands for GBM display.
[snip]
+// scanout from buffer
+static bool
+buffer_flip(struct buffer *buffer)
+{
+struct drm_display *drm = drm_display_init(buffer-dpy);
+if (!drm || !drm-mode)
+return false;
+
+if (gbm_bo_get_width(buffer-bo) drm-mode-hdisplay ||
+gbm_bo_get_height(buffer-bo) drm-mode-vdisplay) {
+wcore_errorf(WAFFLE_ERROR_UNKNOWN,
+ cannot flip buffer smaller than screen);
This error message got me thinking... Maybe waffle_window_create()
should
interpret (w,h)=(-1,-1) as a fullscreen window.
Can we use WAFFLE_WINDOW_FULLSCREEN (or similar) ? Would be nice to
avoid the assumptions and keep everything explicit and clear.
Yeah, WAFFLE_WINDOW_FULLSCREEN is better than (-1, -1). Using a token also
opens up the future ability to intelligently resize the fullscreen window when
the
display resolution changes.
Should we change the name to drm, as currently we relate the platform
name with the display used :P
Nah, let's keep the name unchanged for now. Changing it gives little benefit
but introduces compatibility/conversion headaches.
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH] revert commit 92116dae to make it build with cmake 2.8.12
Jordan and Emil, does reverting 92116dae break anything for you? I don't
have a Debian-based machine, (and this CMake hack was made specifically
to silence Debian warnings), so I don't want to commit this without your ok.
If this revert causes Debian any problems, then I think the next best
thing is to apply the original CMake hack if cmake=2.8.11 and use
PRIVATE and cmake=2.8.12. In fact, that may be better than the revert.
What do you think?
if (CMAKE_MAJOR_VERSION EQUAL 2 AND
CMAKE_MINOR_VERSION EQUAL 8 AND
CMAKE_PATCH_VERSION LESS 12)
# Do old LINK_INTERFACE_LIBRARIES hack.
else()
# Use PRIVATE keyword.
endif()
Matej, Chrome OS also still ships cmake-2.8.11 and is carrying a similar
patch. So I agree with you in that this problem needs to get fixed upstream.
On 12/04/2014 01:22 PM, Matej Cepl wrote:
The commit 92116dae relies on PRIVATE term in target_link_libraries,
which has been included only in 2.8.12.
--- a/src/waffle/CMakeLists.txt
+++ b/src/waffle/CMakeLists.txt
@@ -180,7 +180,7 @@ include_directories(
)
add_library(${waffle_libname} SHARED ${waffle_sources})
-target_link_libraries(${waffle_libname} PRIVATE ${waffle_libdeps})
+target_link_libraries(${waffle_libname} ${waffle_libdeps})
set_target_properties(${waffle_libname}
PROPERTIES
@@ -189,6 +189,13 @@ set_target_properties(${waffle_libname}
VERSION
${waffle_soversion}.${waffle_minor_version}.${waffle_patch_version}
)
+if(NOT waffle_on_mac)
+set_target_properties(${waffle_libname}
+PROPERTIES
+LINK_INTERFACE_LIBRARIES
+)
+endif()
+
install(
TARGETS ${waffle_libname}
LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR}
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
signature.asc
Description: OpenPGP digital signature
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH (maint-1.4)] cmake: Fix building with CMake 2.8.11
Regressed by commit 92116dae.
Waffle's CMakeLists declares that 2.8.11 is required, but commit
92116dae begin using a 2.8.12 feature: the PRIVATE keyword to
target_link_libraries(). We should not bump Waffle's CMake requirement
to 2.8.12, though, because RHEL-7 and Chrome OS still have only 2.8.11.
This patch fixes Waffle to use the PRIVATE keyword only if cmake = 2.8.12.
Otherwise, it falls back to the LINK_INTERFACE_LIBRARIES hack removed by
92116dae.
Reported-by: Matej Cepl mc...@cepl.eu
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
I tested this patch on Chrome OS (which has cmake-2.8.11) and Fedora 20 (with
cmake-2.8.12). I don't have a Debian system to test on.
src/waffle/CMakeLists.txt | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/waffle/CMakeLists.txt b/src/waffle/CMakeLists.txt
index 0e42192..ab10498 100644
--- a/src/waffle/CMakeLists.txt
+++ b/src/waffle/CMakeLists.txt
@@ -180,7 +180,27 @@ include_directories(
)
add_library(${waffle_libname} SHARED ${waffle_sources})
-target_link_libraries(${waffle_libname} PRIVATE ${waffle_libdeps})
+
+# Debian's packaging system emits warnings if wflinfo directly links to any
+# library that it doesn't directly use. Silence the warnings by annotating
+# libwaffle's library dependencies as private, which prevents wflinfo from
+# linking to them.
+if(CMAKE_VERSION VERSION_LESS 2.8.12)
+# On older CMake, we must rely on hacking the LINK_INTERFACE_LIBRARIES
+# property.
+if(NOT waffle_on_mac)
+set_target_properties(${waffle_libname}
+PROPERTIES
+LINK_INTERFACE_LIBRARIES
+)
+endif()
+else()
+# CMake 2.8.12 introduced the PRIVATE keyword to target_link_libraries().
+# All libraries listed after PRIVATE get annotated as such.
+list(INSERT waffle_libdeps 0 PRIVATE)
+endif()
+
+target_link_libraries(${waffle_libname} ${waffle_libdeps})
set_target_properties(${waffle_libname}
PROPERTIES
--
2.1.2.1.g5433a3e
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] [PATCH (maint-1.4)] glx: Fix requirements for creation of ES2 context
On 12/05/2014 04:44 PM, Chad Versace wrote: To create an ES2 context, Waffle required GLX_EXT_create_context_es2_profile. Fix Waffle to require either GLX_EXT_create_context_es_profile *or* GLX_EXT_create_context_es2_profile, because GLX_EXT_create_context_es_profile is an updated variant of GLX_EXT_create_context_es2_profile that supercedes it. Oops. Forgot the bug tag in the commit message: Fixes #24: https://github.com/waffle-gl/waffle/issues/24 Signed-off-by: Chad Versace chad.vers...@linux.intel.com signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [PATCH] wgl: Fix requirements for creation of ES2 context
To create an ES2 context, Waffle required
WGL_EXT_create_context_es2_profile. Fix Waffle to require either
WGL_EXT_create_context_es_profile *or*
WGL_EXT_create_context_es2_profile, because
WGL_EXT_create_context_es_profile is an updated variant of
WGL_EXT_create_context_es2_profile that supercedes it.
Cc: José Fonseca jfons...@vmware.com
Cc: Emil Velikov emil.l.veli...@gmail.com
Fixes #23: https://github.com/waffle-gl/waffle/issues/23
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
Totally untested. I don't have MinGW setup right now. Windows people, please
let know if this patch compiles.
src/waffle/wgl/wgl_config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/waffle/wgl/wgl_config.c b/src/waffle/wgl/wgl_config.c
index 9dea991..59a70a6 100644
--- a/src/waffle/wgl/wgl_config.c
+++ b/src/waffle/wgl/wgl_config.c
@@ -118,8 +118,10 @@ wgl_config_check_context_attrs(struct wgl_display *dpy,
assert(attrs-context_major_version == 2);
assert(!attrs-context_forward_compatible);
-if (!dpy-EXT_create_context_es2_profile) {
+if (!dpy-EXT_create_context_es2_profile
+ !dpy-EXT_create_context_es_profile) {
wcore_errorf(WAFFLE_ERROR_UNSUPPORTED_ON_PLATFORM,
+ WGL_EXT_create_context_es_profile or
WGL_EXT_create_context_es2_profile is required
to create an OpenGL ES2 context);
return false;
--
2.1.2.1.g5433a3e
___
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
[waffle] [ANNOUNCE] Waffle 1.5.0-rc2
Waffle 1.5.0-rc2 is now available. This release introduces new features, of which the most significant is experimental support for the Windows WGL API. Unless someone reports a blocker bug, the final 1.5.0 release will happen tomorrow (Wed 10 Dec). If you want to add additional information to the release notes, then please speak up. Tarballs and other release files are posted at: Release Page: http://www.waffle-gl.org/releases.html#1.5.0-rc2 Source: http://www.waffle-gl.org/files/release/waffle-1.5.0-rc2/waffle-1.5.0-rc2.tar.xz GPG Signature: http://www.waffle-gl.org/files/release/waffle-1.5.0-rc2/waffle-1.5.0-rc2.tar.asc SHA-256 Sums: http://www.waffle-gl.org/files/release/waffle-1.5.0-rc2/waffle-1.5.0-rc2.sha256sums Release Notes: http://www.waffle-gl.org/files/release/waffle-1.5.0-rc2/waffle-1.5.0-rc2-release-notes.txt The SHA-256 checksums are: 56cb08bcd0c1e062e266effc0234852df5f2538edc655dea301105ec390fdf84 waffle-1.5.0-rc2-release-notes.txt ff27e98c6499cfb284baad5ebeec507d62436a3d56bd41a76386df6c6148aaca waffle-1.5.0-rc2.tar.asc b32b0ad8d3746cc9d4198b6ce54bcf442995216cd827429f4c49d36524895166 waffle-1.5.0-rc2.tar.xz The signed git tag v1.5.0-rc2 is found in: git://github.com/waffle-gl/waffle Methods to verify the release files are: Verifying the tarball's signature: xz -d waffle-1.5.0-rc2.tar.xz gpg --verify waffle-1.5.0-rc2.tar.asc Verifying the tag's signature: git fetch --tags origin git tag --verify v1.5.0-rc2 Verifying the tarball's checksum: echo 'b32b0ad8d3746cc9d4198b6ce54bcf442995216cd827429f4c49d36524895166 waffle-1.5.0-rc2.tar.xz' | sha256sum -c Please file bugs and issues at: https://github.com/waffle-gl/waffle/issues Waffle 1.5.0 Release Notes == Backwards compatibility notes - Waffle 1.5.0 is backwards-compatible with Waffle 1.4.0, in ABI and API. New Features * Windows: Experimental support for WGL [Emil Velikov] Emil graciously added support for the Windows WGL API this summer, represented by the new enum 'WAFFLE_PLATFORM_WGL'. The plan is to convert Piglit's Windows build to use this rather than GLUT. * wflinfo now prints the OpenGL shading language version. [Dylan Baker] * Linux: Some library dependencies converted from static to dynamic [Emil Velikov] libwaffle on Linux no longer statically links to, and instead dynamically opens, the libraries below. This change allows a single build of Waffle to be deployed onto systems with and without these libraries. libEGL libGL libgbm * Android: Experimental support for Android Lollipop. (Waffle builds on Lollipop but may have critical bugs). [Yongqin Liu] Bugfixes since 1.4.0 * cmake: Fix building with CMake 2.8.11 * glx: Fix requirements for creation of ES2 context * wflinfo used glGetStringi incorrectly on Mali drivers. * gbm: Workaround Mesa linkage issue * gbm: Remove Mesa warning evoked by waffle_window_swap_buffers(). Contributors since Waffle 1.4.0 --- 80 Emil Velikov emil.l.veli...@gmail.com 39 Chad Versace chad.vers...@linux.intel.com 9 Jordan Justen jordan.l.jus...@intel.com 2 Frank Henigman fjhenig...@chromium.org 2 Yongqin Liu yongqin@linaro.org 1 Dylan Baker dylanx.c.ba...@intel.com 1 José Fonseca jfons...@vmware.com signature.asc Description: OpenPGP digital signature ___ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle
Re: [waffle] nacl backend
On 12/09/2014 04:15 AM, Tapani Pälli wrote: Hi; Hi Tapani :) I'm currently working on a NaCl backend for Waffle, I wanted to ask for opinions or comments on my current approach. Great to hear! First of all I'm using some c++ in the nacl backend code but AFAIK everything of this can be converted to c if c++ is absolutely not wanted. Waffle's Android backend also contains C++, because Android's SurfaceFlinger APIs require it. So, C++ is allowed in Waffle when it's needed. And the Mac backend uses Objective-C... ouch :/ In my opinion, having a mixed C/C++/Objective-C codebase can cause a lot of headaches. So, please try to minimize the amount of C++ code used. Don't, however, zealously and exclusively use C in you NaCl backend if that makes your life significantly harder. If the natural NaCl idiom is C++, then use C++ when iterfacing with NaCl. Does NaCl really provide C bindings the Pepper graphics APIs? I've never closely examined the Pepper APIs before. 1. Building User needs to provide path to nacl_sdk and nacl_version (for example pepper_38). Maybe will need further additions like the target architecture selection (which is currently just hardcoded). For toolchain I've selected 'glibc' as waffle requires dlopen() and c99 support which were not possible when using 'pnacl-clang'. Almost everything builds fine, only failures happen for examples and unit-tests for different reasons (for example fork() or usleep() are not supported + some other symbols caused problems). I've just disabled these for now in cmakefiles when nacl is selected and made my own gl_basic_nacl example which copies the gl_basic test behavior. I'm slowly migrating it to be just like gl_basic but with some minimal changes. All that sounds good to me. My big question: How does one run gl_basic_nacl? Do I need to write a small webpage with javascript glue to load the executable? Does the NaCl SDK provide magic helpers to run it from the command line? 2. Backend Waffle using application is responsible for creating a pp::Instance, either by creating a class or via PPAPI_SIMPLE_REGISTER_MAIN(main) type of wrapper where it gets created behind the scenes. Currently there is no interface to pass this instance to waffle so the backend seeks it out by inspecting a pp::Module::InstanceMap that lists all current instances. I'm working on some patches to expand Waffle's public interfaces to accept flexible parameter lists. Assuming that all current waffle functions will soon be redesigned to accept more flexible parameters, which function would you like to pass the pp:Instance into? Or do you feel that Waffle needs a new entry point for the pp:Instance? Swapbuffers is somewhat complicated as it is asynchronous and app might go and queue another swap before first one finished. Have you encountered any strange NaCl requirements regarding threading? I briefly scanned your code, and did not fully understand what nacl_container.cpp was for. Could you explain that file? When I have a solid solution for this I'm planning to post a set of 'WIP patches', maybe just the build system changes at first. Patches are good! Alpha-quality half-working half-broken patches are good! Patches that build are really really good! I recommend this as a patch submission strategy for your NaCl project: 1. First, submit a skeleton stub implementation of src/waffle/nacl along with the CMake changes needed to build it. These patches should contain nothing controversial; no calls to the Pepper APIs; no example applications. The goal of the first patch series is MAKE WAFFLE BUILD ON NACL. Make any build-system shortcuts and toolchain assumptions that you need to. As soon as these patches arrive, I'll merge it into an integration branch. 2. Second, submit an example program with a thorough explanation of how to run it. It should build and make any needed Pepper calls, but of course it won't work yet because Waffle's NaCl backend isn't finished yet. Having an example program merged early into the tree, before the backend is completed, would allow me and others to play with the NaCl backend as you're working on completing it. 3. Third, start submitting the real implementation of the backend, making any changes to core Waffle as needed. To simplify the effort, focus on getting it working on just one compiler toolchain. 4. Fourth, and partially parallel to 3, start worrying about the other toolchains like PNaCl. If you feel like testing this, I've pushed a snapshot here: http://cgit.freedesktop.org/~tpalli/waffle/log/?h=snapshot Thanks for posting work-in-progress code with your announcement. It really helps to have some concrete code to look at. Looking forward to your patches. signature.asc Description: OpenPGP digital signature ___ waffle mailing list
