On 09/29/2014 10:42 AM, Cedric BAIL wrote: > On Mon, Sep 29, 2014 at 4:08 PM, Chris Michael <[email protected]> wrote: >> On 09/29/2014 10:03 AM, Cedric BAIL wrote: >>> On Mon, Sep 29, 2014 at 3:23 PM, Chris Michael <[email protected]> >>> wrote: >>>> On 09/29/2014 09:17 AM, Carsten Haitzler (The Rasterman) wrote: >>>>> On Mon, 29 Sep 2014 09:06:30 -0400 Chris Michael >>>>> <[email protected]> >>>>> said: >>>>>> On 09/29/2014 07:47 AM, Carsten Haitzler (The Rasterman) wrote: >>>>>>> On Mon, 29 Sep 2014 09:52:23 +0200 Cedric BAIL <[email protected]> >>>>>>> said: >>>>>>>> On Mon, Sep 29, 2014 at 12:46 AM, Carsten Haitzler >>>>>>>> <[email protected]> >>>>>>>> wrote: >>>>>>>>> On Sun, 28 Sep 2014 23:44:32 +0200 Cedric BAIL <[email protected]> >>>>>>>>> said: >>>>>>>>>> On Sun, Sep 28, 2014 at 9:58 PM, Lucas De Marchi >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Em 28/09/2014 08:46, "Graham Gower" <[email protected]> >>>>>>>>>>> escreveu: >>>>>>>>>>>> >>>>>>>>>>>> I've attempted to build using the easy_efl.sh script and received >>>>>>>>>>>> the >>>>>>>>>>>> build error referenced in the subject (full build log follows >>>>>>>>>>>> message). >>>>>>>>>>>> >>>>>>>>>>>> Is there a particular version of udev that is required now, but >>>>>>>>>>>> hasn't >>>>>>>>>>>> been put in the autoconf goo? I have udev 182 on a linux distro >>>>>>>>>>>> without systemd. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> From >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> http://cgit.freedesktop.org/systemd/systemd/tree/src/libudev/libudev.sym?id=946f1825751919a176cd0039002a514de0c9c70f >>>>>>>>>>> >>>>>>>>>>> libudev 199 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Question as always how many distribution ship this library and how >>>>>>>>>> many don't. Should we make 199 mandatory or should we just disable >>>>>>>>>> the >>>>>>>>>> code that require 199 (I guess it is related to wayland). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> since systemd and udev merged... a lot seem to have stopped updating >>>>>>>>> udev >>>>>>>>> at all and may b e on a multi-year-old udev (eg 2011). so our >>>>>>>>> choices >>>>>>>>> are >>>>>>>>> to force an upgrade or work on these distros, or we need a way to >>>>>>>>> emulate >>>>>>>>> this udev call inside eeze iof udev is older. that means someone has >>>>>>>>> to >>>>>>>>> do the emulation code work there. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Do we really need to ? We could just disable Wayland support if udev >>>>>>>> is to old, as I think that is the only think that rely on it. The >>>>>>>> question is more what about other system than Linux. >>>>>>> >>>>>>> >>>>>>> >>>>>>> that makes for a poor eeze api that may or may not work based on a >>>>>>> hidden >>>>>>> udev version at compile time of eeze. >>>>>>> >>>>>> >>>>>> Well, perhaps for the moment we can detect the udev version and just >>>>>> #ifdef the internal eeze code to skip that function call. Fixes the >>>>>> build problem while Not breaking code for people that have a sane udev >>>>>> version. Thoughts ?? >>>>> >>>>> but downside is we have an eeze fn that now is broken for some and not >>>>> others... and then when some try wayland things mysteriously fail.. >>>>> we'll >>>>> hit >>>>> this sooner or later in one form or another. best get it sorted now >>>>> while >>>>> fresh. >>>> >>>> Ok. Makes sense :) >>>> >>>> So...what is the general "agreed" plan for sorting this ?? I've seen a >>>> couple of thoughts on this thread, but no clear plan/path. I don't mind >>>> doing the legwork if we all can agree on a path.... >>> >>> I am voting to put a big eina log warning in that #if for people who >>> have an old version and make sure that when Wayland fail to setup that >>> warning is correctly displayed. After that it is not our duty anymore. >> >> Well, the wayland stuff won't fail without it. It's only used for setting >> the output backlight brightness...so if anything, they won't have backlight >> control, but that's about it. Everything else will be fine. > > Really, that's just it ? Then make it optional is a no brainer in my opinion. >
That is it :) We originally coded the backlight to work directly on the backlight "fd" (raw read/write), however a certain german ;) did not like that approach and opted for udev/eeze approach (which was fine in it's own right)...but in order to set the backlight brightness via udev, we needed that function. Ok, so if nobody has any objections ??? , I'll do some modifications today and #ifdef out that function call with a udev version check.... For those that have ancient udev versions, they won't be able to set backlight levels (when running in drm)...but that's all that will break. dh ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
