On 07/16/2014 03:23 PM, David Seikel wrote: > On Wed, 16 Jul 2014 14:56:23 -0400 Chris Michael > <[email protected]> wrote: > >> 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 ! > > Well, you asked for flames .... B-) > > systemd should definitely be kept optional. It's controversial enough > that a lot of Linux distros are unlikely to use it, including at least > one of the ones I'm thinking of moving to.
Well, Not to fan flames, but I only know of One distro that is not moving to it (due to their own upstart init system) ... but I have heard that even That distro is looking into supporting it in upcoming releases... But please, this is not a "distro war" or "init system" thread... I'm also considering moving > to Wayland, but not if I have to use systemd to be able to actually > input stuff. > > One thing that REALLY annoyed me about the current keyboard stuff is > the horrid way strings are used to send the keystrokes. Strdup'ed from > an internal array, and we have to have our own separate copies of these > strings to do slow strcmp's with. Seriously? Can we at least strshare > them internally? Expose the internal array? > Which current keyboard stuff are you referring to ?? > It's 5AM, I need sleep. > > Yes to combining stuff, no to introducing more deps, yes to cleaning > up the API. Though if it's shown that an embedded ecore_fb single > application thingy can be made smaller using libinput, then that's good. > > Well, the only "certain" dep which would need to be added would be udev for device discovery. The systemd portions of the code could be #ifdef'd. Well, it would be smaller in the terms that ecore_fb would not have to deal with handling input code itself anymore. It currently has it's own code for input events, etc, etc (as does ecore_drm). Those could be unified and end up using ecore_input. 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
