On Fri, 18 Jul 2014 12:54:22 +1000 David Seikel <[email protected]> said:
> On Fri, 18 Jul 2014 11:30:12 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > On Fri, 18 Jul 2014 10:28:05 +1000 David Seikel <[email protected]> > > said: > > > > > On Fri, 18 Jul 2014 08:20:24 +0900 Carsten Haitzler (The Rasterman) > > > <[email protected]> wrote: > > > > > > > On Fri, 18 Jul 2014 05:50:52 +1000 David Seikel > > > > <[email protected]> said: > > > > > > > > > On Thu, 17 Jul 2014 19:49:25 +0200 Cedric BAIL > > > > > <[email protected]> wrote: > > > > > > > > > > > On Wed, Jul 16, 2014 at 10:56 PM, Daniel Kolesa > > > > > > <[email protected]> wrote: > > > > > > > 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: > > > > > > >> >>>> 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. > > > > > > > > > > > > This is irrelevant. Systemd is currently the only one > > > > > > providing a technical solution for non root wayland and a > > > > > > secure environment. There is no other alternative. They do > > > > > > that cleanly with an API and others can just implement the > > > > > > API if they want. It is not our job to fix every damn > > > > > > distribution in the world. We already have enough other > > > > > > things to fix, like all the breakage I do add in. > > > > > > > > > > > > >> >> But please, this is not a "distro war" or "init system" > > > > > > >> >> thread... > > > > > > > > > > > > So true. If you really want to make it a distro war, at least > > > > > > propose an alternative for getting non root wayland working on > > > > > > your beloved distribution. No need to make a useless list of > > > > > > distribution that have no solution to that problem. > > > > > > > > > > I'll cross that bridge if and when I come to it. For now > > > > > though, as mentioned in another thread, I'm putting off > > > > > experimenting with Wayland for my own use. The embedded system > > > > > I also mentioned in this thread only uses FB, not X, so that's > > > > > a separate issue for me, it's not moving to Wayland ever. > > > > > > > > > > > >> >> 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? > > > > > > > > > > > > I don't when that was fixed, but as far as I can remember it > > > > > > is a zero allocation system (Maybe it was me when I rewrote > > > > > > that part years ago, don't remember how it was before). We > > > > > > directly give a pointer to the table from the backend. There > > > > > > is no strdup anywhere between ecore -> evas. > > > > > > > > > > > > >> 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 is not. Now in your application if you really want to micro > > > > > > optimize your strcmp, you can on the first match save the > > > > > > pointer and compare it to that value before doing the strcmp. > > > > > > But seriously, you are never going to see that part of your > > > > > > program showing up in a benchmark :-D > > > > > > > > > > I guess you have never tried to get EFL things running on an > > > > > embedded x486 like I have. :-P > > > > > > > > he's done stb mips. those are slow-arse things. it's in the same > > > > league. > > > > > > Well early testing showed that we were pushing the limits of the > > > hardware, and responsiveness to the "keyboard" input was very > > > important. Luckily the client changed his mind about having > > > EVERYTHING happen at once, which was causing issues, so this became > > > less of an issue. But it was an issue at one point during > > > development, and I was looking at options. So it DID turn up in > > > benchmarking. :-P > > > > > > > > > >> >>> 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. > > > > > > > > > > > > Are you using the fb backend ? > > > > > > > > > > For the embedded x486 project I'm using the ecore_fb backend, > > > > > Edje 1.7.4, Lua, and what ever minimal set of dependencies I > > > > > was able to squeeze it down to. All built on top of a custom > > > > > Aboriginal Linux that was also pared back to the absolute > > > > > minimum. Aboriginal Linux is basically the minimum Linux you > > > > > can get for embedded work that can build itself. EFL 1.7.4 was > > > > > the latest at the time the project finalised, and there's no > > > > > justification for updating that, would cost the client too > > > > > much. This project is actually the test bed I used for > > > > > developing Edje Lua. That client paid for some of the EFL > > > > > development. B-) > > > > > > > > > > The client for that work is looking at a slightly more powerful > > > > > system for a new project, and I'd be happy to see if I can use > > > > > the latest merged EFL for that. > > > > > > > > > > For both these projects there are legal requirements set in > > > > > stone by the local government that state things like "device > > > > > must only include the software strictly needed for the > > > > > functions covered by this legislation, and nothing else". So > > > > > yes, I have to be very serious about keeping things down to a > > > > > bare minimum that we can justify to the governments of at least > > > > > two countries. This is why I worry about such things as > > > > > endlessly adding dependencies. I don't make the laws, but I > > > > > have to follow them. > > > > > > > > i guarantee you that your kernel and libc include all sorts of > > > > functionality you never use there. how have you justified it? you > > > > can nitpick over suck wording or take it as a general guide - eg > > > > don't add a webserver if none was specified. but if a library or > > > > tool you use comes with such requirements then you're stuck with > > > > it unless you do very costly work to remove it - i'd say such > > > > wording is not trying to induce you to do such things. it's > > > > telling you to not add features to code you WRITE that are not > > > > needed, or not add components that are not needed (webserver > > > > above, or irc server or libwebp if webp were an optional support > > > > component and it's not needed for the functionality). > > > > > > Yep, definitely a juggling act between client requirements, legal > > > requirements, cost of meeting them, and reasonableness of the audit > > > labs. Debating on this list to keep excess dependencies out of EFL > > > is something that I CAN do to help though. B-) > > > > unfortunately over the years maintaining all the optional deps has > > become a burden, so we're pushing up the bar - you need more. we ship > > efl as a unit - you get all of it. feedback from almost everyone on > > our efl merge has been positive (so 95%+ prefer it). > > > > > > > > >> 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... > > > > > > > > > > > > The existing old code is mostly broken. It will only work with > > > > > > some configuration if you don't use it to much. We also have > > > > > > zero maintenance nor work going on with it, so quality is > > > > > > never going to reach even close to what libinput can provide > > > > > > (and being shared with other project, it's already better > > > > > > than what we have). Conclusion, either someone step up to > > > > > > unbork and maintain this (with the hope once it is in good > > > > > > shape it is bigger than libinput), or we just rationalize our > > > > > > work and link to libinput and be done with that mess. > > > > > > > > > > > > My point is, current situation is broken and has been for > > > > > > years, if anyone did care it would be in a better shape. So > > > > > > we should be just better switching to libinput. > > > > > > > > > > > > >> I'm flexible in terms of your concerns :) Totally > > > > > > >> understand them ! I'll try to ifdef what I can for ya ;) > > > > > > > > > > > > Yeah, libinput use need to be ifdefed anyway for other system > > > > > > that wont have it. So they should always be able to turn it > > > > > > off, just with a few backend at the same time. > > > > > > > > > > If this new project goes ahead, and when (the client has been > > > > > delaying it for years already), then we shall see if libinput > > > > > suits it, or if I have to turn it off as you mention. > > > > > Certainly udev and systemd would be entirely unwelcome in this > > > > > embedded system, but so is Wayland and X. > > > > > > > > > > On the other hand, the client is considering moving away from > > > > > the current "hardware emulates a keyboard via a > > > > > microcontroller" setup and moving to "just use GPIO to drive > > > > > the hardware directly" setup. So it's entirely possible that > > > > > keyboard input might go away entirely for the new project. B-) > > > > > > > > but as an input level you still have a "keyboard" (gpio inputs per > > > > physical button pressed). to get events you still are going to > > > > likely emulate keys - just not at the kernel level, but higher up. > > > > > > Um no, the board we are evaluating has Linux kernel support for > > > reading / twiddling GPIO pins via /sys/class/gpio/, no need to > > > emulate keys, just read / write pretend files. B-) > > > > that's poor. then: > > > > 1. you must be root to run (bad in almost all siruations isolate > > root access privs to limited binaries) > > /sys/class/gpio/ doesn't imply the need for root. It doesn't matter yes it does. look at it one day. > though, the only way any one can get to the point where they can get > any benefit from being root on the thing is if they get the device open. > At which point, it doesn't matter if they can get root easily or not, > they have full access to everything anyway, including full access to > everything the app has. bugs.vulnerabilities in the user interface app and its libraries - eg point it to display a cleverly crafted jpeg that takes advantage of a buffer overflow in libjpeg or efls' jpeg loader code... and u instantly have full root access, rather that just "as much access as the gui user allows". > > 2. you have no abstraction to speed up development by doing dev on a > > regular desktop first with fast cpu/build/test/run cycles and you do > > fine-tuning on device only. > > What, I can't just point it at /home/onefang/gpio/ and use real files? > B-) hard to press files with your fingers. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ 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
