Page MenuHomePhabricator

ecore_wayland: check to support aux_hint(auxiliary hint) for wayland surface
Closed, ResolvedPublic

Description

there are ecore APIs related with aux_hint.

it is need to check add aux_hint feature into wayland 2.
ex:
ecore_evas_aux_hint_add
ecore_evas_aux_hint_del

ecore_wayland: handle 'aux_message' event and create its ecore event
ecore_wayland: support aux_hint(auxiliary hint) for wayland surface

ECORE_WL_EVENT_AUX_MESSAGE
ECORE_WL_EVENT_AUX_HINT_ALLOWED

ecore_wl_window_aux_hints_supported_get
ecore_wl_window_aux_hint_add
ecore_wl_window_aux_hint_change
ecore_wl_window_aux_hint_del

https://review.tizen.org/gerrit/#/c/48496/
https://review.tizen.org/gerrit/#/c/81478/

Usecase: backward compatability.

If the task was alredy implemented, we will close this task.(To check that the task is alredy implement can be task)

Related Objects

jypark created this task.Jul 24 2017, 7:09 PM
jypark triaged this task as Normal priority.Jul 24 2017, 7:22 PM

Do we really need it ? The proper way to do this in Wayland world is to add a custom protocol. It does carry more meaning and the Tizen Enlightenment team as shown good skill at writting custom protocol so far.

yes we do. discussed repeatedly as to why. it's so people can easily extend when needed ad-hoc for products who have very little clue on what wayland is and how it works etc. without having to generate custom protocols, expose wayland internals or modify efl for products. it's not intended for the "tizen enlightenment team". it's intended for people with far less background and knowledge to get their jobs done easily.

zmike added a comment.Jul 26 2017, 8:43 AM

Based on your description, this feature doesn't seem like something which should be here, as we will never have a conceivable use for it. Why can't this go into the tizen efl repos?

we've had this discussion in email. we've had it in person. it's a patch that needs maintaining that's a delta and it's also useful for prototyping ideas or things that just don't justify all the effort of writing a proper protocol for it. it'd save us time and effort too.

in fact our current way of doing extensions is a mess. ecore_wl2 doesn't wrap a protocol - it totally just leaves you to do wayland protocol directly with static inline funcs that call wl_* funcs directly (libwayland). elementary is DIRECTLY calling the z* funcs from these headers which means elementary has ti link to libwayland itself and basically bypass ecore_wl2. what we have here is a mess of it kind of tries to wrap then fails and just says "how about you do this directly yourself". on the enlightenment side this has just been given up on entirely and it uses a tiny bit of ecore_wl2 and then gives up.

ecore_wl2 tries to look like a wrapper but is a leaky one. very leaky. you want to tell people "just make more of this mess because that's what we do and making an easy simple way for you to add custom compositor <-> client data/property transfer should add to this?". hell we should be using this ourselves to prototype extensions because doing it the way we do is messy, non-obvious and complicated.

we'd benefit from it ourselves. it'd be far cleaner than what we do today...

I am sure I am missunderstanding something here. You are arguing that ecore_wl2 doesn't abstract properly wayland and so we end up using it directly in Enlightenment and Elementary. Now, your solution is to just give up on refactoring and adding the missing abstraction, by having a "protocol" that will just embrace that design by having the meaning of the protocol inside Enlightenment and Elementary instead of inside its wayland protocol. The only way it makes sense, is as a fix for avoiding linking Enlightenment and Elementary directly to Wayland. Is that the only thing we are after here ?

you are asking others to follow our examples ... of how extensions are done. and that is done badly. that's my point.

*IF* you do it this way, firstly you ask people to:

  1. modify efl (elementary, whatever) to add wrappers.
  2. modify app to use those
  3. modify enlightement to handle the other end.

doing this involves learning wayland protocol xml files, wayland scanner AND not even wrapping in ecore_wl2 but exposing as scanned/generated to elem for example, and then using there.

mush simpler for ad-hoc metadata for clients to share with compositor would be the aux stuff. it's just string key, string value. it's simple. we wrap it ONCe in efl all the way up to elementary with elm_win_hint_aux_set() etc. so now only app needsmodification AND compositor just needs to hook into a GENRIC aux handler inside e to read that string key and do something. e.g. some module.

it's less work. it's less to learn. it's simpler to do. it's cleaner than what we already do.

*WE* should use this ourselves when coming up with ideas. we can FORMALIZE THEM LATER in protocol. when we do that we should wrap and hide and do it right (ecore_wl2 should wrap and hide so you are not use zxdg_* or zwnp_* or whatever functions to do this but properly abstracted ecore_wl2 functions). it'd be a stage of development and testing and idea munging ... and it's less work at that stage to use aux hints. LATER once e're happy with the idea and in general how it works it can be transformed into proper protocol.

but there are many people who will NEVER do that. they don't have the time to do it, nor do they care enough. it's internal code between some app and some module loaded in e so the module can get metadata from that app and its surfaces/windows and do something special. that feature may only last 6 months and be thrown out for something else. it's not a core desktop feature. it's something to handle that situation at that time and then move on. it's useful for us to use as a stage before doing a full protocol too. it's generally useful.

Well that escalated quickly.

The general bashing of ecore_wl2 isn't hugely relevant to aux_hints/xatoms-for-wayland. It's also all beta api and unfinished, so declaring its current state a reason to do something in an ugly way is a bit of a non-sequitur. :/

And even when using this aux hint stuff, the:

  1. modify efl (elementary, whatever) to add wrappers.
  2. modify app to use those
  3. modify enlightement to handle the other end.

workflow doesn't really change that much? I guess step 1 disappears, but you still have to modify enlightenment to do something with the hint, and modify the app to set it? So we're removing the burden of coming up with concise function names in step 1, and saving the trouble of not-dumping-all-that-code-into-a-gigantic-switch-statement in step 3?

I'd also like to point out that aux_hint really isn't "generally useful" - wayland protocol is capable of carrying file descriptors and arrays, it's incredibly asynchronous, and many current protocols have latching state. It also carries documentation in the xml file. This key+string hack is really just for prototyping the tiniest subset of wayland protocol - setting a property on a surface. Basically single request/single event.

Once you're past the boilerplate - ie) tizen.xml already exists, and an implemention already exists (it does, it's in the tizen repo right now) adding new protocol this simple is really just a few lines of code. You add callback to an array, you add a the event in the xml file.

Really though, I can't think of a "full protocol" that this could usefully assist in prototyping, since it's so small in scope. But I can think of a lot of ways it'll be a serious pain for long term maintenance and a serious barrier to cross desktop compatibility if it ever sees use in upstream efl/enlightenment.

zmike added a comment.Jul 27 2017, 9:23 AM
In T5780#92933, @raster wrote:

we've had this discussion in email. we've had it in person.

I'm moderately certain that we've never discussed this in person, and I'm 99% certain (after looking through all of my inboxes) that this has never even been casually mentioned in any mail that I've sent or received.

In T5780#92935, @raster wrote:

*WE* should use this ourselves when coming up with ideas. we can FORMALIZE THEM LATER in protocol

It seems you have this misconception that writing wayland protocol is some arduous process involving lots of trial and error. It's not. You have the idea, you write the protocol, you're done. Your proposal to use this during development adds overhead by necessitating extra steps: writing based on these aux hints, then later rewriting with wayland protocol--something which is unnecessary since writing the intended protocol is easy enough in the first place.

In T5780#92935, @raster wrote:

but there are many people who will NEVER do that. they don't have the time to do it, nor do they care enough. it's internal code between some app and some module loaded in e so the module can get metadata from that app and its surfaces/windows and do something special. that feature may only last 6 months and be thrown out for something else. it's not a core desktop feature.

If this is your strongest argument, then I'm fine with upstreaming it (and all other useless-to-upstream-developer ideas) with a --enable-tizen flag which allows this and all related code to be compiled out by default. At the very least, this ensures nobody looking at a release build will see these ideas being shipped and write another dailywtf article about us. At best, it prevents the widespread upstream use of what is effectively a technical debt-creating mechanism.

The general bashing of ecore_wl2 isn't hugely relevant to aux_hints/xatoms-for-wayland. It's also all beta api and unfinished, so declaring its current state a reason to do something in an ugly way is a bit of a non-sequitur. :/

this is totally relevant. the answer is "don't add aux hints - do it via protocol" and our examples of doing it via protocol and our examples of "this is how you do this" are definitely not pretty, clean or well done... so effectively "just this hacky thing with no clean wrapping or namespacing"... it's pretty bad to put that up as an example.

I guess step 1 disappears

one very very very big step disappears. one that is actually not necessary (if we have aux hints). you are saying to people "go figure out where in this 1.2 million lines of code or so where to do this, figure out that it's actually a code generator coming from Makefile.am and not even Makefile_Ecore_Wl2.am ... then rebuild all of efl (which takes a very long time)... and remember the issue is also a people one. almost all the time these people who have to do this are not allowed to modify efl. they then have to talk to another team to do that and request they do this work for them because it's not their project. they have to rev 3 moving pieces (compositor, client app and efl), of which efl is by far the larges and most complex. it's nuking the hardest and most time consuming and complex step. revving a rebuild of efl takes a very very very long time. this is in addition to the other 2 unavoidable bits (modifying client and compositor). it's a huge change in workflow for the better. this is for metadata transport that very likely will be private and never be formalized in any way. it adds a whole layer of work for something that is often going to be throw-away. Remember this is for people who know very little about wayland or its protocol or how it works. they have no idea what the protocol xml files are and have to go learn all of this. Remember the common workflow is to build packages... so this involves rebuilds (as packages are build then installed). yes i know that workflow is inefficient.

it also does not hurt us to have this feature ourselves and use it where appropriate to save time. so ok. then we just refuse to accept these api's and patches upstream. that means others have to maintain a delta because we are stubborn and can't even accept what is actually harmless code. it does not hurt us. it's not going to actually break things or create a maintenance burden worth talking about.

I'd also like to point out that aux_hint really isn't "generally useful" ... etc.

you do know this is how x11 atoms worked basically for 30 years... and almost every single window property/feature was built on top. like 90% of all features of windows were built off simple key->value pair properties (atoms not strings for key and data is a binary blob... but same concept). sure. with aux hint you'd need callbacks when they change (which one changed) etc. ... but that's part of a decent protocol design for it. it's covered broadly above. so are you telling me that what x has used for 30 + years for 90% of what it has done with windows is not generally useful?

Once you're past the boilerplate - ie) tizen.xml

see above. the people modifying the compositor are not allowed to touch efl. they have to request a separate team for permission to do that or get them to do it. they do not have the efficiency of "just touch every bit of code needed across N repos and get it done" that we do. aux hint is a way of dealing with that by cutting out some of that overhead. i see no reason why not to support it upstream too and force people to carry patches for something that is very useful to them. it's not exactly a large amount of code nor is it invasive nor is it complex.

serious barrier to cross desktop compatibility if it ever sees use in upstream efl/enlightenment.

as for compatibility ... i don't see any of this pain you mention. if we did custom protocols instead it'd be the SAME problem. only one compositor (e) would speak that protocol thus the same exact problem comes. we're going to have custom protocols that are not going to be generally accepted. so will kde and gnome. so will others too. this is nothing new.

I'm moderately certain that we've never discussed this in person

Actually I think that was a meeting you missed - you went home early and didn't stay for further face to face metings... thus missed it.

There is an email thread "About Tizen EFL upgrade" is the subject... derek and chris both were involved but looking at the cc list you were not on it.

so i'm sorry - you didn't get this... but i have seen/heard/been involved in many discussions including several of you guys who are working efl/el in wayland space and i remember this being discussed again and again. i didn't go check who was on that to/cc list as it was in my work email box which i can't get to from home... i just checked.

so yes - you were not in these. others were though. cedric sure was involved in face to face and email threads... so indeed sorry - you specifically were not. everyone else though was. yay for not having mailing lists and yay for missing f2f meetings (for whatever reasons).

It seems you have this misconception that writing wayland protocol is some arduous process

see my response to derek above. it's not that it's arduous. it's that it's unusual (code generation) and the people who need to adhoc extend don't know this and having to learn it is a barrier and it makes them unhappy. they can maintain patches because we re stubborn, or we can compromise. make their lives a lot easier and not be really much skin off upstream's back. it will even prove useful to upstream as i mentioned.

If this is your strongest argument, then I'm fine with upstreaming it

i don't see the value of having either the api's or their implementation's ifdefe'd just don't use them if you have a better solution (ie protocol). that is in and of itself already messy and needs cleaning up.

shipped and write another dailywtf article about us

Oh come on. you know full well most of that was baloney. 100 lines to add 3 buttons to a box was just plain incompetence when it can be done in 9. now reading the docs and examples was another. that kind of person is going to go after anything they can because they have an axe to grind. this kind of api has nothing to do with it. the idea of being able to just set arbitrary string -> value pair properties on a window isn't exactly bizarre not is it unusual. this has been done for 30+ years in x. it's worked very well. yes the xml protocol is "cleaner and more precise" but it's also more work having to touch more moving parts, one o them is efl and its big.

In T5780#93055, @raster wrote:

remember the issue is also a people one. almost all the time these people who have to do this are not allowed to modify efl. they then have to talk to another team to do that and request they do this work for them because it's not their project.

Again, we are discussing upstream contributions, which are seen and used by everyone and not just people working on Samsung product teams. In that scenario, this argument is irrelevant, as those people are not even using upstream versions of the code.

In T5780#93057, @raster wrote:

you went home early and didn't stay for further face to face metings... thus missed it.

If you're referring to the one day of private meetings that I wasn't in HQ for, I was informed that this would be exclusively for discussing multimedia and kernel projects and that it would be a waste of time and budget for me to attend.

There is an email thread "About Tizen EFL upgrade" is the subject... derek and chris both were involved but looking at the cc list you were not on it.

so i'm sorry - you didn't get this... but i have seen/heard/been involved in many discussions including several of you guys who are working efl/el in wayland space and i remember this being discussed again and again. i didn't go check who was on that to/cc list as it was in my work email box which i can't get to from home... i just checked.

so yes - you were not in these. others were though. cedric sure was involved in face to face and email threads... so indeed sorry - you specifically were not. everyone else though was. yay for not having mailing lists and yay for missing f2f meetings (for whatever reasons).

Okay, so again you are citing more private meetings and mail threads as reasoning for what is unanimously agreed upon as a poor technical contribution to public upstream repositories.

In T5780#93057, @raster wrote:

Oh come on. you know full well most of that was baloney.

The point isn't whether the article was technically relevant, it's that it's literally the only thing that people remember now when discussing enlightenment/efl. It gets linked in every reddit thread, every HN thread, every slashdot thread, literally 100% of the places where efl/enlightenment are mentioned publicly. And yes, I mean "literally" in reference to the dictionary definition of the word. If you can't see past the minutiae of factual inaccuracies in the article to understand how such a thing was extremely damaging to our entire ecosystem and future growth potential, then I have no further arguments to make.

It seems like no matter what is said there is no possible way of changing your mind on this or any other idea you are championing, and this has been the case for quite a while. I've tried to be reasonable, I've tried to offer compromise solutions, and I have remained open to discussion and having my mind changed should valid technical arguments present themselves, but all of these things have been to my detriment since your response will never change and I will only have wasted my own time, your time, and the time of anyone who follows our discussions.

I am giving up on trying to provide any form of technical analysis for all ideas and patches that you or anyone else from HQ proposes. I will unilaterally approve 100% of all submissions without reading or reviewing them, since it seems that this is your expectation of me. It's my hope that this will reduce friction between us, improve our ability to collaborate in the future, and, ideally, decrease the amount of time that you spend disparaging most of my contributions in public. As a gesture of good faith, I've implemented full support from this feature to the best of my ability based on the implementation in Tizen's git repositories.