I have merged some of these API functions today, so this patch will most certainly not apply cleanly anymore. There are still a few APIs on this that are not in upstream yet (mostly cursor APIs, and the input rectangle one).

@eagleeye @CHAN This patch will need to be rebased before anything can be done with it due to the Ecore_Wl2.h changes

@CHAN I added some more tests today and marked them off the list, However there is an issue with some of these functions (ones I marked with ?? at the end). Basically, I don't see how we can write tests for these functions because they only support a 'set'. As an example, ecore_wl2_window_class_set function ... We can make a test which executes that function, but we have no way to verify that the class actually gets set...

This will likely need to be rebased against EFL master due to the Ecore_Wl2.h file changes

I believe this task is now finished. All of the API functions inside Ecore_Wl2.h are now documented upstream. I will leave this ticket open for now in case more API gets added shortly.

Looks fine here

In D9215#193877, @CHAN wrote:

ecore_wl2_window_input_rect_set(Ecore_Wl2_Window *win, Eina_Rectangle *input_rect)
ecore_wl2_window_input_rect_add(Ecore_Wl2_Window *win, Eina_Rectangle *input_rect)
ecore_wl2_window_input_rect_subtract(Ecore_Wl2_Window *win, Eina_Rectangle *input_rect)

Those APIs created for two or more input areas.

Anyways, In contrast to ecore_wl2_window_input_rect_set(), the ecore_wl2_window_input_region_set() has additional features. (pending update.)
So now those two APIs has a bit different behavior.

We can use ecore_wl2_window_input_region_set() instead of ecore_wl2_window_input_rect_set(),
if there is no pending update feature in the ecore_wl2_window_input_region_set() API or if we support it.

@devilhorns Do we need to update it asynchronously(pending)? if so, we need a ecore_wl2_window_input_rect_set() API. and any opinion about it?

I would have preferred a more descriptive error message, but since this is just in a test it's fine.

This is working now. Fixed by commit https://git.enlightenment.org/core/efl.git/commit/?id=13ecc4898c23aa58421a847efbe5392d2b18cef8

I would think these should use EINA_TRUE, EINA_FALSE for consistency, yes ??

Ah ok, no worries then

Seems to me this could just use a bool rather than an int...

@stefan_schmidt I tested this with everything updated this morning. It works just fine when using software rendering, however when I try to test with gl rendering, nothing works .... not even elementary_test :( so I am unsure what to do here.

@stefan_schmidt Yes, I am actively looking into this. Apologies for missing your message on the 13th, but for some odd reason, I did not get a Phab email about it :(

Great work !! :) We cannot push this upstream yet tho because of the freeze for 1.23 release. After the freeze is over, I will push these changes.

eeze is Required for ecore_drm2 so the answer is No, it was never supported to build drm without eeze