Announcement

Collapse
No announcement yet.

Enlightenment's Ecore Now Has DRM Support

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Enlightenment's Ecore Now Has DRM Support

    Phoronix: Enlightenment's Ecore Now Has DRM Support

    Enlightenment's Ecore library now has support for interfacing with the kernel's Direct Rendering Manager drivers...

    http://www.phoronix.com/vr.php?view=MTYyMzU

  • #2
    Originally posted by phoronix View Post
    Phoronix: Enlightenment's Ecore Now Has DRM Support

    Enlightenment's Ecore library now has support for interfacing with the kernel's Direct Rendering Manager drivers...

    http://www.phoronix.com/vr.php?view=MTYyMzU
    Except this isn't just for Samsung Tizen, this is for running enlighenment (the actual enlightenment component of E) as a 'bare metal' Wayland compositor. Just using efl/ecore support will only support 1 application at a time (unless you use tty switcping). I thought an Enlightenment developer (devilhorns) already said this in the other thread
    Last edited by nerdopolis; 03-06-2014, 12:52 PM.

    Comment


    • #3
      Originally posted by nerdopolis View Post
      Except this isn't just for Samsung Tizen, this is for running enlighenment (the actual enlightenment component of E) as a 'bare metal' Wayland compositor. Just using efl/ecore support will only support 1 application at a time (unless you use tty switcping). I thought an Enlightenment developer (devilhorns) already said this in the other thread
      Is this practically useful for anything other than having graphics during early boot, or having accelerated graphics for each tty?

      Comment


      • #4
        Originally posted by liam View Post
        Is this practically useful for anything other than having graphics during early boot, or having accelerated graphics for each tty?
        how do you think weston works? or xorg itself (kms)? this is how you get to do buffer flipping, vsync, mode switching (kernel) etc. - and its the core of making a compositor that goes direct to kernel interfaces to get its stuff done.

        Comment


        • #5
          Originally posted by raster View Post
          how do you think weston works? or xorg itself (kms)? this is how you get to do buffer flipping, vsync, mode switching (kernel) etc. - and its the core of making a compositor that goes direct to kernel interfaces to get its stuff done.
          So, you've created a new display server that doesn't use make use of either the x or wayland protocol?
          Perhaps I'm not understanding something?

          Comment


          • #6
            Originally posted by liam View Post
            So, you've created a new display server that doesn't use make use of either the x or wayland protocol?
            Perhaps I'm not understanding something?
            no - drm/kms support gives the ability to do accelerated display direct to the kernel (framebuffer). this is the basis for weston, for xorg (modern xorgs that support kms and use drm - not older drivers or non kms based drivers). this is the same basic stuff but put into a library and api so anyone can use it easily. this same library is used by enlightenment as well as efl toolkit in general, so the same support can allow someone to make a display system of their own, or a wayland compositor, or just draw direct to fb with acceleration... etc. - we're using it for making enlightenment a stand-alone wayland compositor.

            Comment


            • #7
              Originally posted by raster View Post
              no - drm/kms support gives the ability to do accelerated display direct to the kernel (framebuffer). this is the basis for weston, for xorg (modern xorgs that support kms and use drm - not older drivers or non kms based drivers). this is the same basic stuff but put into a library and api so anyone can use it easily. this same library is used by enlightenment as well as efl toolkit in general, so the same support can allow someone to make a display system of their own, or a wayland compositor, or just draw direct to fb with acceleration... etc. - we're using it for making enlightenment a stand-alone wayland compositor.
              Isn't that what I said?

              So, you've created a new display server that doesn't use make use of either the x or wayland protocol?
              However, you say that one could use this new lib to create their own display server (isn't that exactly what the lib already is?) OR as a Wayland compositor (thus indicating that this ISN'T a new protocol like I said), or just drawing to the fb but accelerated (so, like directfb... yet a different "protocol").
              So, rather than this being a new display protocol, like I was claiming, you seem to be saying it is a wrapper around the kms api (which, I'm told, is rather difficult to use directly)?
              If so, that does seem quite useful, generally.

              Best/Liam

              Comment


              • #8
                Originally posted by liam View Post
                Isn't that what I said?
                no it's not. you asked if it's a new display server. it's not. it's not a server of any kind. it does not accept clients (multiple) or arrange access to input devices for other client processes. it's for a single process to access the display devices directly via kms/drm. you can take the lib and MAKE a process that is a display server, but the lib is NOT a display server. it is just utility code a process can use. a process can become a server if it accepts clients connecting to it. the kms/drm stuff has nothing to do with clients at all - it's device/display access for a single process. it's useful far beyond just graphics at boot or accelerated graphics per tty... it's the foundation for being able to build things like xorg, weston etc. etc.

                Originally posted by liam View Post
                However, you say that one could use this new lib to create their own display server (isn't that exactly what the lib already is?) OR as a Wayland compositor (thus indicating that this ISN'T a new protocol like I said), or just drawing to the fb but accelerated (so, like directfb... yet a different "protocol").
                So, rather than this being a new display protocol, like I was claiming, you seem to be saying it is a wrapper around the kms api (which, I'm told, is rather difficult to use directly)?
                If so, that does seem quite useful, generally.

                Best/Liam

                Comment


                • #9
                  Originally posted by raster View Post
                  no it's not. you asked if it's a new display server. it's not. it's not a server of any kind. it does not accept clients (multiple) or arrange access to input devices for other client processes. it's for a single process to access the display devices directly via kms/drm. you can take the lib and MAKE a process that is a display server, but the lib is NOT a display server. it is just utility code a process can use. a process can become a server if it accepts clients connecting to it. the kms/drm stuff has nothing to do with clients at all - it's device/display access for a single process. it's useful far beyond just graphics at boot or accelerated graphics per tty... it's the foundation for being able to build things like xorg, weston etc. etc.
                  I definitely wasn't thinking that a display server had to serve more than one client in order to be considered a server
                  OK, as you say it can be the basis for a server, if you want to accept clients, but it immediately gives a process the ability to draw accelerated graphics to the fb.
                  Again, is it fair to call this a wrapper to the kms/DRM APIs? I mean currently, if you want an accelerated display server, or even something like kmscon(but accelerated) you'd have to use kms/Drm APIs directly.
                  Sorry for being obtuse about this

                  Comment


                  • #10
                    Originally posted by liam View Post
                    I definitely wasn't thinking that a display server had to serve more than one client in order to be considered a server
                    OK, as you say it can be the basis for a server, if you want to accept clients, but it immediately gives a process the ability to draw accelerated graphics to the fb.
                    Again, is it fair to call this a wrapper to the kms/DRM APIs? I mean currently, if you want an accelerated display server, or even something like kmscon(but accelerated) you'd have to use kms/Drm APIs directly.
                    Sorry for being obtuse about this
                    well it's not a wrapper. i would consider a wrapper something that intends to just hide the "nasty ugly raw details" of a lower level api and make it simpler. this is more than that. this glues in all of evas (canvas - scene graph) to render to kms/drm. not just wrap a raw frameuffer with swapping and mode setting, but to make the scene graph target this display device, so it's many layers up the tree (though we build everything ourselves on top of this higher level scene graph).

                    Comment


                    • #11
                      Originally posted by raster View Post
                      well it's not a wrapper. i would consider a wrapper something that intends to just hide the "nasty ugly raw details" of a lower level api and make it simpler. this is more than that. this glues in all of evas (canvas - scene graph) to render to kms/drm. not just wrap a raw frameuffer with swapping and mode setting, but to make the scene graph target this display device, so it's many layers up the tree (though we build everything ourselves on top of this higher level scene graph).
                      I thought it WAS addressing kms/drm directly. That this is intended to allow evas to run directly on the fb explains why my I confused. Yes, you can accelerate a tty/boot, and write a display server with it but none of those capture the actual target.
                      Thanks for the explanation. This makes much more sense and explains why you did it.

                      Comment

                      Working...
                      X