Yea....not going to happen

Every time they release a new OS lots breaks. Maybe it'd be best to tackle all these when 11 is public. There's all sorts of issues with windows and scaling need addressing. Is it worth spending time now to fix things with no idea what next is going to break in the forthcoming macOS 11 this year?

Marcel, I've no longer access to a macOS machine. If someone would send me one I'd gladly look into any of these issues. I'm reassigning to @bu5hm4n as he is the last person I know who did any macOS-specific work...

move to here - i can't reproduce any of the above issues. works perfectly for me. what os AND video drivers?

In T8053#138426, @devilhorns wrote:

I suspect this is due to a change in the xdg_wm protocol

i think you can also just take a normal elm_test window, and set the hint_min_size to something bigger than your screen.

uggg ok. It's gonna take me a few days to get started on this then :( My new Rpi4 has not been delivered yet

elm_test, my screen on my raspberry pi is quite small.

and what window did you use that has a min size bigger than your screen ?

Get a window with a minsize bigger than your screen, -> maximize.

How did you get this error ? Reproduction steps ?? I updated my box, efl and e from git this morning, but when I launch elementary_test with Weston, I do not get this message :(

I suspect this is due to a change in the xdg_wm protocol. I will look into this tomorrow

Tested on Vbox and on the Beast with terminology and this seems to work fine.

@ApB Can you retest this please and let me know if it still happens with current git ??

probably not even an error we can fix. this is probably something to bring up with the appropriate driver developers, but even then may never be fixed. also note you may hit a limit at 126/127/128 or so or maybe 254/255 as xorg has a limit on client connections and last time i hit it, it was 128 clients (e will have 1 connection at least itself to start). so you'll hit a wall/limit like that that will probably be far before you hit a ram limit these days. as i said the 20/30 limit smells like a driver/gpu limit in maximum number of contexts or something similar. we impose no limit in efl and even if we did it's be per process, not globally.

Probably not getting fixed any time soon

87cf5188b466d3fa1e8c8ff7ad6d5039b28e298a should sort this.

i don't even know that we get an error or can detect it. we do things like check the return of glxcreatewindow and error out and complain what failed. it seemingly is not failing. if we don't see things failing from the glx/egl api then we can't do anything about it.

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.

Support for elogind has been upstreamed for a while now