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.

this isn't a task description nor a bug report and over a year old. please reopen and be more thorough what this is about,

@maxerba any thoughts here? is the module still developed?

@barbieri this is from your commit: 02d352e1f29

I often see videos in rage at fullscreen size (not maximized, real fullscreen) and many times it happens that on a desktop notification arrival from whatever app (thunderbird, telegram, network-manager, ...) rage exits from fullscreen mode, so I have to re-fullscreen it via the F key.

this happens to me especially on high system load on linux (video rendering, swapping) and then i see enlightenment is using half of my cpu. most of the times this happens the only way to recover is to restart enlightenment.

In T7051#124941, @charlesgwaldman wrote:

I haven't seen this problem in a while

EDIT: I tried to unplug one of my monitors. With only one monitor issue seems to disappear.

In T4827#95163, @zmike wrote:

Wasn't there some other ticket related to this?

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

fixed by D7014, yet forgotten to close.

you've set this task for enlightenment 16. is that correct? enlightenment 16 was released as 1.0 in 2009, but is still supported. however currently enlightenment has been rewritten and is completely different from enlightenment 16. if your bug concerns enlightenment 16, please contact <kim@woelders.dk>. if not, please reopen and state your current enlightenment and efl version. your distribution version would probably also help. thanks.

@billiob shouldn't you be used to already to have terminology resizing because $WHATEVER ? :D

yes, sorry, but you weren't really good at describing the problem. can you be more thorough and maybe add some screenshots?

this is probably part of the solution to T3438

maybe @devilhorns wayland patches will solve this - on wayland.

Other times, if I am very quick I can switch to a tty and kill -9 enlightenment.

The rest of the time, my system becomes completely non-responsive. I cannot: ctrl+alt+backspace, ctrl+alt+del, switch to a tty,

I am using LFS based linux distribution.

yes, this is because default in e you can configure nearly everything ;-)

chrome? chromium? firefox? something else?

where is this line of code?

@netstar could you have a look at this?

anything happend here? might add goal tag?

is this still an issue?

is this still an issue? did you report on gtk as zmike suggested?

entrance only has seen recent development in the forked repo from @wltjr, who has been "in conflict" with other e developers. however, entrance development seems to have been stopped by the enlightenment team. so this is very likely still an issue, but the resolution inside the fork doesn't seem to be compatible now.

can you get a valgrind log?

are you able to test, if you use an open source gpu driver (like radeon, noveau), if this happens with kernel 4.13? because since kernel 4.14 I've got some wacky problems.

i'm still learning phabricatror....

typo, U instead of I: NUM_TRUES != NUM_TRIES

In T7318#123910, @bu5hm4n wrote:

In T7318#123897, @ProhtMeyhet wrote:

this could make the solution much simpler: only use eina_file_path_sanitize for setting the key in the hash table, but not for opening the file itself. however, stat is also called anyways, so why not get the information from there?

No this is still a bad idea, since 2 paths (A,B) which are pointing to 2 different files can still point to the same file after eina_file_path_sanitize. And well I dont see how you can get the full path of a file from the stat structure ...