Someone (I will say no names) changed what happens when you Iconify a window in E....

not happy with this yet .... I see Windows...

Installing to $PREFIX is typical for custom built software.....

In D12154#232414, @raster wrote:

ordering change - yup. thumbs up. not sure wit the if (intcount == 0) had to go in to make it longer code.... but like the other patch checking init returns.. is there really a neeed?

I miss eapps... lol

Part of the problem becomes ... do we go by WL standards ? or X11 ?...

state min is state min .. hidden is hidden...

when a window is iconified to the IBox, its WM_STATE remains as "Normal" rather than "Iconic".

@JAFO I will send you a branch link when it's ready......

I would like to have ya on the testing list ... when it's ready to be tested...

In D12248#234287, @ali.alzyod wrote:

In D12248#234281, @devilhorns wrote:

Reject right now because I Believe this to be Approved by Spam ....

Until further discussion, this....needs to sit....

I believe request change means you have something against the patch but reject because it was approved by SPAM is something strange :)

edje_cc would not be your problem wrt a joystick...

Reject right now because I Believe this to be Approved by Spam ....

Why Does Enlightenment Fail ... IF/When EFL is ok ???

I can't use you EOF because of the path(S).....

DBG is debug...... NOT Fail

If DBG is causing a fail ... then that tells me you May have an EINA_ABORT set somewhere ...

I've read the joystick code here for Ecore_Input ... THIS should not be the cause of your ABORT >>....

It is Sounding like you have an EINA_ABORT set on somehing ... DBG would NOT cause an ERR..........

Did the pulse Service name change ??

Modify your local copy to read:

Warnings should not cause Failure to my knowledge .. unless you have an Eina_Abort set or something....

There may be an E mixer logging domain that could be enabled with debug code to find the problem......

This is not a problem that @raster should have to deal with ... I can fix what's wrong if others gather....

@abrouwers don't give up ... this Can be fixed...

@ProhtMeyhet Mixer prolly needs a patch...

netstar expressed a concern and Did Provide some code that Could have helped...

To Me, It looks like your Code is Out of Date.....

Not sure why I am the reviewer here ... but I really am the wrong person for this as I don't know pulse or alsa, etc, etc

I am confused wrt this ...

@dpollack No particular link ... just git master is fine

I am looking through the current code and it seems this is no longer an ERR message ... downgraded to a Warning in the current codebase... that's why I was wondering if this was still an issue because the code has been changed....

@abyomi0 Is this still an issue ??

I pushed a fix for this issue: 95a88f5a6c5c8bcc8bacb014

I did not take into consideration distros which do not keep up ... I can revert it ... Sorry

@vtorri A huge Thank You for your hard work here !!!

Looks ok to me now. @Hermet ??

@vtorri This is looking Soo much better....

It starts to build now :) but getting lots of build issues ... I've attached a log of the build output

In D12235#233946, @Hermet wrote:

3 years later and not a single movement on this ... closing

Yea....not going to happen

Beta tag for Ecore_Wl2 upstream will stay for now as things will likely change there shortly

Nothing has been done with this in over a year, so let's drop it

This makes sense, but could you provide a better Summary please...

I'm not Sold on this one Yet....

+1. Please Commit. Approved !

In T8866#154744, @cederom wrote:

The question is why don't we use WLROOTS and SEATD so the project gets portable and does not contain hard references to Linux only solutions like systemd/logind? If we had that solution Enligthenment would already work using Wayland both on Linux and FreeBSD :-)

Do you know these solutions? Is it a lot of work to add another WL glue (wlroots+seatd)? Any sort of estimate form experienced developer would be nice to know :-)

In T8867#154720, @cederom wrote:

Still the core question remains - if EEZE is a mandatory requirement for DRM? If not then DRM code does not respect meson configuration :-)

Currently, the DRM implementation in EFL is coded to use Eeze for discovery of the drm card and other devices. Systemd or elogind is also a requirement currently. As I do not use *BSD, I would be unable to code support for that (as I cannot test it), however if you would like to provide patches then I would be happy to review.

Likely it is because of "/sys/class" ....

#4 0xb7e4a411 in __dlclose (handle=0x0) at dlclose.c:46
#5 0xb1ab76ad in e_drm2_compat_shutdown () at ../src/modules/../bin/e_drm2.x:65

Execute Same using SW engine, THEN let me know it fails....

" tty with enlightenment_start (Wayland is used), it seems to start fine. Then opening uxterm (Xwayland),"......

Yes, I know .... This is still missing in Master branch...

In D12169#233047, @raster wrote:

this isnt wrong.. it's just a bit ugly... maybe just managed -> int and if (managed > 0) in later if's... :)

fbcon can get touch support....so let's not dump that yet...

I agree here ....

setenv(ECORE_DRM2_CARDS="xyz")

There is a part of Enlightenment settings that does Not properly respect WL ones ....

There is an ECORE_DRM2 env Var that you can use to Set the Proper Card(s) or two...

The stringshare_del in #10 looks wrong here ....

Right Here ....

I Know, I KNOW .... There will not be a third screen Until I can Find some Help with certain parts....

Has anyone started to look @ this yet ?