On Mon, 4 Nov 2019 16:41:15 +0100 michael bouchaud <michael.bouch...@gmail.com> said:
> 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 This shouldn't be necessary. In drm/fb mode the window will automatically be told it's focused. it works for me without such a workaround in terminology... i can type in: elementary_test -to "Entry 3" no problems. no workarounds in elementary_test.... :) > 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 -- ------------- 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
