2014-07-16 21:16 GMT+01:00 Chris Michael <[email protected]>: > 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. >
Also Gentoo/Funtoo. > > >> 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 > ------------------------------------------------------------------------------ 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
