On 07/17/2014 11:35 PM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 16 Jul 2014 14:56:23 -0400 Chris Michael <[email protected]> > said: > >> Hello devs :) >> >> There was a brief discussion on IRC today regarding using libinput (of >> wayland fame) for other input related things in EFL (aside from drm). >> Cedric mentioned that it could be used for fb and various other >> engines/platforms. This would allow us to unify handling input devices >> under one efl library. >> >> Ecore_Input seems the likely candidate to me....So I am writing to get >> any additional comments/remarks (before going through the effort of >> changing things). >> >> One thing that I have noticed in the current ecore_input code is the >> namespacing seems wrong. The actual ecore_input codebase uses >> ecore_event as the API namespace (ecore_event_init, etc, etc). This just >> seems sooo wrong to me :( One thing I would like to do (open for >> discussion), is to unify this into ecore_input_init, etc, etc to make >> the API functions match the library namespace...However this would mean >> depcreating the existing ecore_event_init APIs (yes, mark them as >> deprecated, but internally just make the code call the newer >> ecore_input_init, etc). >> >> Another thing we could do here is to bring in udev dependency and do >> input device discovery :) This would unify things so that we don't >> duplicate code (ecore_drm does this, ecore_fb could benefit from it, >> etc, etc). >> >> Yet a third thing Could be to (compile time optional) bring in the >> systemd deps from ecore_drm and have ecore_input handle opening >> /dev/input devices and feeding those events. This would also unify and >> reduce code duplication. >> >> Please bear in mind this is an RFC so nothing is concrete yet. I am just >> trying to gather ideas/thoughts/concerns/comments, etc, etc Before I get >> started on the work. >> >> Flame On ! >
Wonderful !! :) Thank You, this is the sort of input (no pun intended) that I was asking for. > yes ecore input does some evil things namespace-wise - thought tbh we have far > too many libraries and namespaces for our own good. so let's not worry about > that except in an efl 2.0 view - ie that ecore_input is merely an internal > part > of efl - not intended for consumption by the general development world and is > "external" simply as a bi-product of many years of building layers on layers. > Well, the only namespacing changes I was considering would be to deprecate the ecore_event_init/shutdown functions (which afaict are only used internally in efl anyway) and replace those with ecore_input_init/shutdown (more appropriate naming). Aside from those namespacing changes, anything else related to ecore_input would be namespaced appropriately (ecore_input_devices_list, etc, etc). > as such any udev and systemd deps will need to be ifdefed internally - if not > there, then fine - don't have them work. please have it abstracted enough to > allow it to be filled in for other environments in the future (eg systemd/udev > replaces by other thnigs), but for now - don't worry about making things work > outside of systemd+udev (the udev rolled into systemd). it can be up to > someone else to do the work of supporting ubuntu (upstart) or gentoo (with > their separate udev and dont want systemd in core approach) etc. etc. - if > systemd makes life easier - then support it. if that means wayland and efl > support only works on systemd systems - so be it. it's the practical course > and people who do not want to follow can do their own support work asnd submit > patches. > Well, considering that both libinput and systemd have udev deps already, we may be able to get away with not requiring udev (as a hard dep) at all. I use it currently in some drm code to get the list of initial input devices, but (afaik) libinput already provides api for that anyway. Sure. Am all for the ifdef dance ;) There will probably be more ifdefs than actual code (j/k) ;) Well, since "the old man", and "the french borker" are in favor of this, I'm going to go ahead and start planning/hashing out things & get the ball rolling. If anyone else has feedback/input on this, please voice your opinions soon, or forever hold your peace ;) dh ------------------------------------------------------------------------------ Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
