On Wed, 16 Jul 2014 16:16:35 -0400 Chris Michael <[email protected]> wrote:
> 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 ;) Thanks. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
