Ahhh ok, that makes sense. Thanks.

@CHAN I moved the ecore_wl2_window_aux_hint functions to be internal now as they are not used anywhere outside of EFL itself. I also removed the test case for the one function that was there.

This issue is now fixed in Enlightenment git head

In D11007#209238, @CHAN wrote:

@devilhorns

Yes in weston my sample app is not work.

When i tried to launch sample app the log said.

"zxdg_surfacc_v6@16: error 3: xdg_surface has never been configured. "
"_begin_recovery_maybe() Wayland Socket Error: Protocol error "

in enlightenement there is a "xdg_wm_base" value in global interface.
but weston there is no "xdg_wm_base" value in global interface.

Any idea about it?
i will try to figure out what is going on here.
Um... but i think the ecore_wl2 is not works well on weston.
weston doesn't have efl only protocols...
i dont have many experience about it though...
anyway i will look around more.

Please give me any advise for this.

I just run enlightenment_start and build efl on enlightenment then run the TC and sample test apps.

Thanks.

@CHAN Ok, I went through the list of API functions here and have found which ones are not done yet. The list of these functions is below. I would suggest making new patches for these because this current patch will certainly not apply cleanly any more. Another suggestion I have is to separate it into a patch for ecore_wl2_window functions, and another patch for ecore_wl2_input functions. An even Better suggestion would be a separate patch for Each Function. This will allow easier review and be easier to follow any comments, suggestions, or discussions that will take place.

In T8016#149260, @devilhorns wrote:

In T8016#149233, @CHAN wrote:

@devilhorns

Now the ecore_wl2_output_find failed.

output list gets a value when _surface_enter() being called.

According to wl doc
(This is emitted whenever a surface's creation, movement, or resizing results in some part of it being within the scan out region of an output.
Note that a surface may be overlapping with zero or more outputs. )

It should be called if i create a win and move it. but its not called...

any idea about it?

I took a look into this ... and from what I can see going on, the issue is that we never get the _surface_enter event. This could be due to the surface Not Actually being shown on screen ... but I am not 100% sure yet and will keep digging into it

In T8016#149323, @devilhorns wrote:

In T8016#149293, @CHAN wrote:

@devilhorns

Thanks for giving me an answer and adding a new TC.

I have a question about other APIs.

ecore_wl2_dnd and ecore_wl2_offer APIs looks that support Copy & Paste between or within windows using wl protocol.
If then, I wonder if these APIs will be usable when open to the public. Tizen also uses only internal modules.

ecore_wl2_subsurface APIs...
These APIs are hard to determine for what usability.
Could you please tell me more about what these APIs are used for? In Tizen there is no case used.

I will have to take a look at where the dnd, offer, and subsurface functions are used in our codebase. It is possible that some of these can be moved to Internal functions.

In T8016#149322, @devilhorns wrote:

In T8016#149295, @CHAN wrote:

@devilhorns

input = ecore_wl2_display_input_find_by_name(disp, "default);

You added above line in TC.
In my env the value is "seat0" instead of "default".
So it failed.

Do we work on different env?

I can change it to be "seat0", that's no problem

In T8016#149293, @CHAN wrote:

@devilhorns

Thanks for giving me an answer and adding a new TC.

I have a question about other APIs.

ecore_wl2_dnd and ecore_wl2_offer APIs looks that support Copy & Paste between or within windows using wl protocol.
If then, I wonder if these APIs will be usable when open to the public. Tizen also uses only internal modules.

ecore_wl2_subsurface APIs...
These APIs are hard to determine for what usability.
Could you please tell me more about what these APIs are used for? In Tizen there is no case used.

In T8016#149295, @CHAN wrote:

@devilhorns

input = ecore_wl2_display_input_find_by_name(disp, "default);

You added above line in TC.
In my env the value is "seat0" instead of "default".
So it failed.

Do we work on different env?

In D11007#208736, @CHAN wrote:

@devilhorns

I'm working on ubuntu 18.04.

I install enlightenment with meson build -Dwl=true and drm disable.
and then open enlightenment with command 'enlightenement_start'

Then build efl with command 'meson build -Davahi=false -Dcxx=false -Decore-imf-loaders-disabler="ibus, scim" -Dharfbuzz=false -Dwl=true -Dx11=false'

After then running TC with command 'meson test ecore_wl2-suite'

The result is fine.

96%: Checks: 29, Failures: 1, Errors: 0
../src/tests/ecore_wl2/ecore_wl2_test_window.c:168:F:Window:wl2_window_output_find:0: Assertion 'out != ((void *)0)'    failed

Um.. please let me know timeout happen in which test case?

@CHAN I had to revert these tests because they can cause the Ecore_Wl2 test suite to timeout/stall. I executed them here and they would timeout/stall 75% of the time.

In D9215#208408, @CHAN wrote:

@devilhorns Hi, any issue on it?

In T8016#149233, @CHAN wrote:

@devilhorns

Now the ecore_wl2_output_find failed.

output list gets a value when _surface_enter() being called.

According to wl doc
(This is emitted whenever a surface's creation, movement, or resizing results in some part of it being within the scan out region of an output.
Note that a surface may be overlapping with zero or more outputs. )

It should be called if i create a win and move it. but its not called...

any idea about it?

In T8016#149222, @CHAN wrote:

@devilhorns

Derek said iconified is not work properly in this commit 50a9b49acca943754f603bd45aa4fa5b9f5020b6

Can i move it (ecore_wl2_window_iconified_set) to internal?

@CHAN The other thing I would like to get your opinion on is: What do you think about using Ecore_Evas inside the Ecore_Wl2 test suite ?? It would allow us to make tests that require user input, and also allow us to check that the window functions are working correctly because it would let us create an actual window, without having to specifically need EGL/GL.

@CHAN The buffer API functions where moved to be internal because they were not being used anywhere else other than inside EFL itself.

@CHAN This looks good to me now, thanks for the changes :)

One little minor fix needed.

@CHAN The issue with this is because Ecore_Wl2 does not actually handle any drawing. If we used Ecore_Evas in this test suite, then it would be a simple thing to do. However, Ecore_Wl2 window does not handle any actual rendering so in order to get it to "draw" a window, we would need to manually create a wl_buffer and attach it to an Ecore_Wl2 window. After doing that, it is still problematic because there is no rendering loop in Ecore_Wl2, so getting any changes to draw in the Ecore_Wl2 window would require a lot of code...

This looks fine, go ahead and push it

This looks ok to me ... but I honestly did not read Every line to double check the email addresses

I hate to be a pain here, but our usual convention is to put the EINA_UNUSED after the parameter ...

@CHAN To be honest, I am unsure. Aux Hints support was something that mike added. I will take a look through the code and see if I can find out how it is meant to be used.

Looks good to me, but lets get one more sign-off to be sure

This patch is no longer needed as I have moved the buffer_transform function to be internal. It is unused outside of EFL internals

This patch is no longer needed as I moved the buffer_attach function to be internal

@CHAN Sadly I do not have any better idea to test the window_free function :( It does not return a boolean or anything that we can compare