On Fri, 18 Jul 2014 12:09:20 +0900 Carsten Haitzler (The Rasterman) <[email protected]> wrote:
> 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. Like I said, it doesn't matter anyway. > > 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". You are assuming this device in some way allows people to point the application at random jpegs. Or any other files. > > > > 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. :) You are assuming the device in some way involves people pressing it with fingers. Simple enough to script up tests to twiddle with these files and pretend to be the real hardware. For these devices, that's all that is needed for a suitable abstraction. Neither of your assumptions are true. And this discussion has long since drifted off topic. BTW, I DO know what I'm doing, I'm a professional. B-) -- 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
