On Mon, 4 Nov 2019 20:02:32 +0800 (CST) Jing <chenjing...@126.com> said:
> 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.
When using drm, it'll not be using the old ecore_fb input code. it'll be using
libinput instead. this is the library that xorg itself and right now all the
wayland compositors use to get input device ... input.
first try this:
elementary_test -to "entry 3"
can you type in the entry boxes there? does that work? you should be able to
switch focus around and type things in...
you also should be using the *EVAS* and *ELEMENTARY* key input layers, not the
lower level ecore ones. you can set focus on evas objects, liset for key
down/up callback on specific objects, grab keys to a specific object (if that
key is pressed, it is delivered on that object you grabbed that key to). there
is a whole system for focus handling and deciding where key events go
etc. ... :)
> 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
--
------------- 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
