Hi Jing,
As you're running now your app without window manager you need to tell your
app is focused.
Check the code into terminology with the nowm option (check below).
https://git.enlightenment.org/apps/terminology.git/tree/src/bin/main.c#n656
Regards
Le lun. 4 nov. 2019 à 13:03, Jing <chenjing...@126.com> a écrit :
> Hi Carsten,
> Follow your advice, i change to use drm method and the image tearing issue
> is fixed now, but i met new issue that, the application layer can not
> receive the KEY/BUTTON UP and DOWN events any more.
> _ecore_fb_li_device_event_key() in ecore_fb_li.c can received the event,
> but in application layer i use function
> ecore_event_handler_add(ECORE_EVENT_KEY_DOWN, keyDownCB, cardstack); The
> callback function will not be called.
>
>
> Please help to advise how fix this issue, many thanks.
>
> At 2019-09-28 01:34:32, "Carsten Haitzler" <ras...@rasterman.com> wrote:
> >On Fri, 27 Sep 2019 13:42:09 +0800 (CST) Jing <chenjing...@126.com>
> said:
> >
> >> Hi Carsten,
> >>
> >>
> >> Thanks for your reply. You are saying "drm can be vsynced and tear-free
> even
> >> if it is configured without gl-drm", right?
> >
> >drm is separate to gl_drm. drm is software rendered but with display
> target of
> >drm/kms. gl_drm is opengl rendered with a display target of drm/kms. kms
> allows
> >for tear-free vsynced display of buffers direct to "the framebuffer" (not
> >fbcon which is the old single front-buffered kernel fb display).
> >
> >> But from source code in
> src/modules/ecore_evas/engines/drm/ecore_evas_drm.c,
> >> it seems only enabling vsync with option BUILD_ECORE_EVAS_GL_DRM, how
> can we
> >> build efl to enable vsync without gl-drm package:
> >
> >drm/kms vsync by design. google "kernel mode switching" :) just try it...
> >
> >> #ifdef BUILD_ECORE_EVAS_GL_DRM
> >> if (tinfo && gl)
> >> {
> >> char *num;
> >> Evas_Engine_Info_GL_Drm *einfo = tinfo;
> >>
> >> einfo->info.vsync = EINA_TRUE;
> >>
> >> num = getenv("EVAS_DRM_VSYNC");
> >> if ((num) && (!atoi(num)))
> >> einfo->info.vsync = EINA_FALSE;
> >>
> >> einfo->info.dev = edata->dev;
> >> einfo->info.bpp = edata->bpp;
> >> einfo->info.depth = edata->depth;
> >> einfo->info.format = edata->format;
> >> einfo->info.rotation = ee->rotation;
> >> einfo->info.output = edata->output;
> >> if (!evas_engine_info_set(ee->evas, (Evas_Engine_Info *)einfo))
> >> {
> >> ERR("evas_engine_info_set() for engine '%s' failed",
> ee->driver);
> >> goto eng_err;
> >> }
> >> }
> >> else
> >> #endif
> >>
> >>
> >> Looking forward to your reply, thanks.
> >>
> >> At 2019-09-23 22:13:11, "Carsten Haitzler" <ras...@rasterman.com>
> wrote:
> >> >On Mon, 23 Sep 2019 14:02:09 +0800 (CST) Jing <chenjing...@126.com>
> said:
> >> >
> >> >> Hi Carsten,
> >> >> Thanks for your reply. Correction: Actually, we didn't use X11 and
> only
> >> >> use frame buffer, based on our flash and memory performance
> considering,
> >> >> we are using a light configuration, here is our configuration for
> your
> >> >> reference. Our system do support basic drm, but vsync needs gl_drm(we
> >> >> didn't have gl accelerate), do you have any simple option to avoid
> tear
> >> >> issue or implemented a simple ping pong buffer mechanism.
> >> >
> >> >there's gl_drm that needs gl accel an also just drm which is software
> >> >rendered, but uses kms/drm to display buffers. this will be vsynced and
> >> >tear-free. the fb backend will tear because of the reasons i already
> gave in
> >> >the previous mail. :)
> >> >
> >> >> --with-tests=none --disable-systemd --disable-doc
> --disable-cxx-bindings
> >> >> --enable-fb --disable-cocoa --disable-poppler --disable-spectre
> >> >> --disable-libraw --disable-xcf --disable-libmount --disable-audio
> >> >> --disable-avahi --disable-pulseaudio --disable-xinput2 --disable-xim
> >> >> --disable-scim --disable-ibus --disable-elua --without-glib
> --with-x11=none
> >> >> --with-opengl=none --without-x --without-mount --without-umount
> >> >> --without-eject --disable-image-loader-bmp --disable-image-loader-dds
> >> >> --disable-image-loader-tgv --disable-image-loader-xpm
> >> >> --disable-image-loader-webp --disable-image-loader-wbmp
> >> >> --disable-image-loader-tiff --disable-image-loader-tga
> >> >> --disable-image-loader-psd --disable-image-loader-pmaps
> >> >> --disable-image-loader-jp2k --disable-image-loader-ico
> >> >> --disable-image-loader-gif --disable-gstreamer1 --disable-xinput22
> >> >> --disable-librsvg --disable-vg-loader-svg --disable-vg-loader-eet
> >> >> --with-crypto=none --disable-doc --disable-v4l2 --disable-libvlc
> >> >> --with-net-control=none --disable-libeeze --disable-gesture
> >> >> --disable-xpresent --disable-cserve --disable-always-build-examples
> >> >> --with-profile=dev --disable-physics --disable-valgrind
> >> >> --disable-quick-launch
> >> >>
> >> >>
> >> >> Looking forward to your reply, thanks.
> >> >>
> >> >> At 2019-09-21 15:53:12, "Carsten Haitzler" <ras...@rasterman.com>
> wrote:
> >> >> >On Sat, 21 Sep 2019 13:47:40 +0800 (CST) Jing <chenjing...@126.com>
> said:
> >> >> >
> >> >> >> I use efl-1.21.1(define the image/rect in edc file) to develop in
> linux
> >> >> >> environment. Using X11 and framebuffer. Looking forward to your
> reply，
> >> >> >> thanks.
> >> >> >
> >> >> >what framebuffer engine/rendering path? in x11 what rendering
> engine? what
> >> >> >windowmanager/compositor?
> >> >> >
> >> >> >tl;dr; short version: this stuff is complicated and crosses lots of
> >> >> >software boundaries (protocols, kernel vs xserver vs client vs
> multiple
> >> >> >toolkits vs compositor etc.). i'll cover some of those details
> below s
> >> >> >you didn't tell me everything above.
> >> >> >
> >> >> >if you are using the fb engine for framebuffer rendering, then it
> has no
> >> >> >vsync or double buffering support. it's built on the old /dev/fb
> interface
> >> >> >and mmaps the existing fb and renders to cpu local memory then
> copies
> >> >> >stuff to the framebuffer. thus it will tear at times. that's life
> with
> >> >> >fbcon as it doesn't have buffer swapping semantics (it could
> allocated
> >> >> >double-height buffers and do panning... but it still has no ability
> to
> >> >> >explicitly vsync this so will still lead to tearing). that's why
> there is
> >> >> >a drm engine... thus sues drm/kms as the framebuffer interface
> which does
> >> >> >have swapping/atomic/vsync semantics and will then not tear. this
> is the
> >> >> >engine that e uses as a wayland compositor (well drm or gl_drm
> depending
> >> >> >if you have gl accel on or not).
> >> >> >
> >> >> >with software rendering in x11, no mechanism exists to explicitly
> avoid
> >> >> >tearing for clients (ignoring the double buffer extension in x
> which
> >> >> >doesn't actually provide SWAPPING mechanics and leads to worse
> performance
> >> >> >anyway. it at best does copies from the backbuffer to the window...
> - i
> >> >> >can go into gory details if you want).
> >> >> >
> >> >> >if you have no compositor in x then rendering goes straight to the
> >> >> >frontbuffer framebuffer. by that i mean the update regions once
> filled by
> >> >> >the cpu in shared memory are COPIED over to the window which lives
> in the
> >> >> >framebuffer. if it's composited then these regions are copied to the
> >> >> >pixmap that represents the window and the compositor will, at some
> point
> >> >> >after that render that pixmap to its own backbuffer and swap and the
> >> >> >compositor itself may also tear in its presenting to the screen
> depending
> >> >> >on the compositor you have. i have seen compiz (the compositor
> ubuntu has
> >> >> >used for unity) EXPLICITLY do copies to the front buffer to try to
> do
> >> >> >partial update rendering to reduce rendering amount BUT at the
> expense of
> >> >> >always tearing. that's why i asked.
> >> >> >
> >> >> >efl/e only does this in the software path - with the gl path we
> always
> >> >> >buffer swap and request vsynced swaps if asked (tear-free0 for the
> >> >> >compositor. we can't do anything about the client rendering, but if
> >> >> >clients use gl as well and do swaps then they have a chance of the x
> >> >> >implementation doing proper buffer swaps (not copies) from the gl
> >> >> >backbuffer to the composited target pixmap (exchange the buffers if
> sizes
> >> >> >match). again - depends on your compositor/wm and how it may
> reparent
> >> >> >windows and do frame draws. e doesn't draw frames via x when
> compositing
> >> >> >but does it in-compositor making the client pixmap an exact 1:! of
> the
> >> >> >client window with frame drawn around it only in the compositing
> step.
> >> >> >other wm's compositors may reparent and raw frame inside the parent
> >> >> >window, thus forcing x to copy to the composited pixmap, thus
> tearing...
> >> >> >
> >> >> >wayland avoids this by using CSD (client side decorations) and
> being an
> >> >> >explicit buffer presentation protocol, thus being designed from the
> >> >> >ground up to avoid tearing as long s e everyone does everything
> right.
> >> >> >tearing in x is "part of life".
> >> >> >
> >> >> >if you have the right compositor you can reduce tearing but it will
> ever
> >> >> >go away in x. in theory i could have designed a private x11 display
> >> >> >protocol between efl and e and literally do what wayland does -
> present
> >> >> >whole pixmaps with update/damage region metadata via x client
> messages
> >> >> >and have the x compositor render them without tearing but it'd be
> then
> >> >> >only for efl apps using software rendering in enlightenment and
> nowhere
> >> >> >else. this would still result in extra copies if e is also software
> >> >> >rendering as a compositor and i'd have to actually do a private shm
> >> >> >buffer sharing scheme between efl clients and x... and even then the
> >> >> >compositor itself will still tear as there is no way for a software
> >> >> >rendering compositor to ensure it gets to atomically present an
> updated
> >> >> >render buffer in x11 ... unless we move to gl. :)
> >> >> >
> >> >> >> At 2019-09-20 20:55:53, "Carsten Haitzler (The Rasterman)"
> >> >> >> <ras...@rasterman.com> wrote:
> >> >> >> >On Fri, 20 Sep 2019 18:48:14 +0800 (CST) Jing <
> chenjing...@126.com>
> >> >> >> >said:
> >> >> >> >
> >> >> >> >> Hi all,
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> I met a problem that when i slide the screen(mouse move), the
> edge of
> >> >> >> >> the image or rectangle object will tear( appear jagged, see my
> >> >> >> >> attached snapshot). I have set various values with
> >> >> >> >> ecore_animator_frametime_set, but there is no improvement.
> What can
> >> >> >> >> I do to fix this issue? Please help, thanks a lot.
> >> >> >> >
> >> >> >> >what environment? x? wayland? what is rendering the object? what
> kind
> >> >> >> >of environment?
> >> >> >> >
> >> >> >> >--
> >> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> >> >> >> >-------------- Carsten Haitzler - ras...@rasterman.com
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> enlightenment-devel mailing list
> >> >> >> enlightenment-devel@lists.sourceforge.net
> >> >> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >> >> >
> >> >> >
> >> >> >--
> >> >> >------------- Codito, ergo sum - "I code, therefore I am"
> --------------
> >> >> >Carsten Haitzler - ras...@rasterman.com
> >> >
> >> >
> >> >--
> >> >------------- Codito, ergo sum - "I code, therefore I am"
> --------------
> >> >Carsten Haitzler - ras...@rasterman.com
> >>
> >> _______________________________________________
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >--
> >------------- Codito, ergo sum - "I code, therefore I am" --------------
> >Carsten Haitzler - ras...@rasterman.com
>
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Michaël Bouchaud
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
