On Wed, 16 Jul 2014 15:30:53 -0400 Chris Michael <devilho...@comcast.net> wrote:
> On 07/16/2014 03:23 PM, David Seikel wrote: > > On Wed, 16 Jul 2014 14:56:23 -0400 Chris Michael > > <devilho...@comcast.net> 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... As well as Aboriginal Linux, which I use for embedded work. > 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 ?? Evas_Event_Key_Down->key Unless that got fixed and I never noticed? > > 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. Yes, but while the ecore code gets smaller, would still have to add libinput to the embedded system, plus any other extra dependencies. So THAT's the point I'm making, whether or not the total footprint gets bigger or smaller. A client asked me recently to see if I can cut down the boot time of his embedded system a bit more by removing more stuff. Since he has finally decided to stick with two boards instead of his random plethora of boards, I can cut the Linux kernel drivers down to the bare minimum. For this current project the use of pre merged EFL was set in stone some time ago, since it was built before the merge. For his next project, I would like to see if I can use merged EFL, but still able to cut the total footprint down to "something not bigger". Udev and systemd are just plain bloat for this sort of thing, simply not needed for anything else. The devices are fixed, the init is a simple script that mounts things than calls the single app. Libinput could work if the total footprint of the system doesn't bloat. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
