[waffle] Windows workflow and updates

[Chad Versace]

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.