could you try to disable Hardware Acceleration in firefox?

In T8047#141333, @deepfire wrote:

this sounds like an out-of-memory situation, or generally high system load.

Far from it. Plenty of CPU/RAM free. No OOM in sight.

No zram used.

In D9734#180629, @Herald wrote:

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

i've been playing around with this a bit and it seems it is caused by the locking mechanism of the package manager.

I can't help you much here because I'm on holidays and I only have my phone. I'll come back in early September.

raster fixed an SEGV on close in 0.22.4 with rE638ffe58538478ede9f9000db370ec5e853635e8 and i had a SEGV which was closed with rEbf146faf7289035eade9875735869de4da7622d4.

strange, did it ever work for you/on fedora?

and then the checkmark again.

does it change when you press the refresh button in the popup menu?

two things

I'm sorry it took so long for anyone to answer, but the picture

In T7803#139702, @cederom wrote:

not really :-( some issues that i have noticed:

1. ui hangs but mouse moves. sometimes after several minutes things get back to normal sometimes not.
2. window switcher / selector is buggy. almost always with virtualbos running it cannot switch back to other windows and does not show windows on the list while switching with Ctrl+Tab. this is critical as i have to restart session and interrupt my work.
   
   that never happens on the same machines running xfce4 or lxqt..

I have failed to find a suitable man page of the clock module. As such i am unable to understand what the ci->week.start = 1 should actually do. it gets configured, all right, but what it actually should do ... ?

I'll have to assume you are using linux.

the pastebin already died. however you can upload a file here on this bugreporting page, which i hope you'll do.

In T7803#134209, @cederom wrote:

Thank you Peter! Enlightenment really rox! Just as my beloved FreeBSD!

The argument (basic) is added to the layout string (ru (basic) instead of just ru) and libxkbcommon throws an error

When a new window opens it will render -for a split second- a picture from another xwayland app.

Enlightenment by default stores a crashlog in your home directory called ~/.e-crashlog.txt. please delete this file, as every crash will be appended to it, and then crash enlightenment again. then please upload the newly created ~/.e-crashlog.txt.

this sounds like an out-of-memory situation, or generally high system load.

I am sorry, but i am very confused by your ticket. However you seem to have resolved it, or it may have resolved itself.

this should be solved with terminology 1.5.0. please reopen if it wasn't.

this is really hard. it doesn't look like a hardware issue and i'm afraid we have to make you debug further...

In T6240#139620, @Hi-Angel wrote:

Hey guys, I wanted to take a stab at it, but my question is: is there a way to build terminology separately from the whole enlightenment project? I.e. so I could work just on this feature alone?

Could you please provide the Enlightenment and Efl version you are using? devd, pulseaudio and dbus version would probably also help.

seeing those, too. T8095

for me this seems to be resolved with 1.5.0. thank you!

In T8095#139135, @billiob wrote:

Could you please test with Terminology 1.5.0 or ask to have it on opensuse?

In T7097#129282, @raster wrote:

this smells here like a video driver issue - like there are a limited number of "contexts" (video ports) for output rendering and once you hit the limit things fail. that's what it smells like at any rate... so either a hardware or driver design limit. the numbers above hint that the limit might be 64 which smells like the kind of number that might be such a limit well some ports are used implicitly e.g. the screen/compositor uses 1 then it gets 63 mroe of them (port 0, 1, 2, ... 62) then the 65'th fails.

In T6462#129422, @raster wrote:

git log src/lib/ecore/efl_io_closer_fd.c

to see full changes

git log --color -U src/lib/ecore/efl_io_closer_fd.c

and you'll see what we both mean.

In T6462#129418, @raster wrote:

what @bu5hm4n said - i looked at the history of the file - the commit went in - changes there then at a later point it was changed again by other commits. so in GIT it seemed all fine to me.

In T6462#129413, @raster wrote:

it's just the cgit gui web - git has all the right state/content. that's what matters at the end of the day.

In T6462#129083, @raster wrote:

ummm errrr? i don't know. cgit might have caches like @cedric says and these somehow got stale or unwritable or... ?

oh, forgot: it's been over one whole year since i opened this, so "cache issue" sounds unlikely @cedric

@raster any idea?

see also T7439

In T7439#125432, @ManMower wrote:

can you try setting the ELM_DISPLAY env var to "wl"

elm apps try X first by design. if both a wayland compositor and an X11 server are running, trying X first is generally least surprising (because wayland apps will connect and run even if WAYLAND_DISPLAY is unset).

In D7471#130784, @ManMower wrote:

How is it possible that the rpi3 is beating the i7s? I realize the pointer sizes are different, but that still seems improbable? Your golden sample PI3 is also beating the odroid in the eina_list test. I think that alone needs further investigation? :)

since, you know, old hardware is still great which is why i use linux and enlightenment in the first place:

apparently resolved.

Then Linus made a joke about Greg being big and squishing people that may or may not be playful or insulting, without knowing much about the relationship between these guys it's hard to say. Squish is hardly a word you use when you're really angry though.

i think this is related to my tasks T3441 and T3590 which both have to do with .desktop file parsing, caching and closing of a window or menu.

xterm uses a concept from X called cut buffers. i never understood it myself and there are many people who neither.

In T7409#126655, @devilhorns wrote:

I've seen this before and (iirc) if you "unset DISPLAY" it works .. not sure why tho, could be something in elementary's detection at startup (ie: it sees DISPLAY as being set and tries to run in X11)

you should be able to adjust scale in Settings -> Look -> Scale Settings.

this was fixed in enlightenment in 2013 with T485 commit 8ad5e3db391df1cc98051d2f94877245a0b2ca27

there have been a lot of changes between enlightenment 0.20 and 0.22 in calculating window width/height. could you check if this is still an issue with latest enlightenment and efl?

on phab, if you just type in the hash value of the commit, it will generate a useful link to git:

seemingly this has something to do with efreet, which is caching mime lookups?

reaction time: just about 24 minutes. i am proud of you @netstar :-)

there are some comments left with the same spelling error:

yes something has to run as root in order bootstrap login.

at the end i had to resolve to remove geany, go back to enlightenments gui Default Applications and press apply once.

still an issue. i get the following messages:

somewhere somehow solved.

In T7373#125843, @kzeiler wrote:

I'm a Gentoo user who is having this issue with both enlightenment 0.22.3 and 0.22.4 and efl 1.20.7 and 1.21.0. Using nouveau and mesa-18.2.4 and am now on kernel-4.14.78. I'd already tried removing my .e and .elementary directories to no avail.

Attached is dump of what I got from valgrind invoking it from xinitrc. I do scientific programming in Fortran and Python and haven't touched C or C++ in years (and very little even then), so this is definitely not in my wheelhouse. I can change valgrind parameters if needed and do any further testing as time permits and with reasonable direction.

i actually feared it was this again... X not answering enlightenments call.

In T7443#125791, @thierry1970 wrote:

That does not solve my problem.