Enlightenment's Ecore Now Has DRM Support

[phoronix]

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

[nerdopolis]

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

[liam]

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?

[raster]

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.

[liam]

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?

[raster]

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.

[liam]

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

[raster]

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.

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

[liam]

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

[raster]

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).