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
