On 07/16/2014 03:59 PM, David Seikel wrote: > On Wed, 16 Jul 2014 15:30:53 -0400 Chris Michael > <[email protected]> wrote: > >> 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... > > As well as Aboriginal Linux, which I use for embedded work. >
Fair enough :) Hard to keep track of every single distro and what they each use lol. >> 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? > Ahh I see. Hmm, well I don't see anything inside of ecore_input_evas.c which is strduping/strcmping the keys ... but perhaps that is happening before or after ecore_event gets things... >>> 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. > Ah, I see your point now. Well, for your specific case (I think) it will end up being even because we would add libinput dep (which is pretty small last I looked), but we would be reducing ecore_fb code size... > 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. > Libinput itself is about 56k (currently). Upon further inspection, it seems libinput now handles the necessary udev code itself so we won't need an extra dependency there... PKG_CHECK_MODULES(MTDEV, [mtdev >= 1.1.0]) PKG_CHECK_MODULES(LIBUDEV, [libudev]) PKG_CHECK_MODULES(LIBEVDEV, [libevdev >= 0.4]) (more info: http://www.freedesktop.org/wiki/Software/libinput/) Well, what I/we can do is to #ifdef around the newer libinput stuff for ecore_input that way you can build without it (if desired). When ecore_input stuff is "finished", then we can #ifdef inside ecore_drm and ecore_fb to use ecore_input or use the existing old code... I'm flexible in terms of your concerns :) Totally understand them ! I'll try to ifdef what I can for ya ;) 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
