[fritsch]

That works perfectly fine as long as you don't use Unity what you both most likely do. See this launchpad bug: https://bugs.launchpad.net/ubuntu/+sourc...ug/1521302 - works fine with fluxbox

Edit: With the fixed compiz and current Krypton branch it also works on unity.

[pemartins]

I don't use Unity and it is reported to happen in more:

Errors when switching from fullscreen to windowed mode at least occur with XFCE (xfwm), MATE (metacity) and LXDE (Openbox) and Fluxbox WM.

Actually in that report Unity wasn't even mentioned https://trac.kodi.tv/ticket/17062

I don't use compiz also. Happens to me in two different OS, one with Openbox and the other with Xfwm.

ps- not talking about the fix because I did not test it, I don't know how.

[fritsch]

You can backup .Kodi and test with a nightly. Afterwards downgrade again.

With unity: compiz is meant as unity bases on it.

[pemartins]

So I'm assuming that that fix is already in the latest nightly, right?

If so I just tested it in a virtual machine using Linux Lite 3.4 32bit (Xfce, xfwm) and I have bad news and good news:

- the bad news is that "\" key does absolutely nothing

- the good news it that I created a xml file inside ~/.kodi//userdata/keymaps with this content:

Code:

<?xml version="1.0" encoding="UTF-8"?>

<!-- Button Ids: -->
<!-- 0: left -->
<!-- 1: right -->
<!-- 2: middle -->
<!-- 3/4/5/6: extra -->

<keymap>
<global>
<mouse>
<click id="2">togglefullscreen</click>
</mouse>
</global>

</keymap>

and by pressing the middle mouse button it works flawlessly. By clicking the middle mouse button coming out of fullscreen to windowed mode Kodi now remembers both windowed's size and place.

[fritsch]

Post a Debug Log please with you pressing "\" - I think it's a keyboard layout configuration issue and "\" is not doing what you think.

[pemartins]

I'm so sorry, you're totally right and it does indeed work.

So many years using VMs and the one time I had to test a key which is always misconfigured to portuguese keyboard I forgot to set portuguese keyboard layout on the VM...

So it is working as expected, I believe the issue is solved.
Thank you very much for everything.

[fritsch]

Thanks to you for coming back and being that polite even with me being snippish at times :-)

[pemartins]

when I shade or iconify Kodi 17.x during video reproduction, after restoring the normal window the video reproduction freezes for some seconds

if I suspend my laptop with Kodi executed, even if inactive, when I resume my system Kodi fonts and mouse cursor go blur and monochrome (I have no idea what the right terms are) and make every menu unreadable and the mouse and Kodi unusable. Here's a printscreen:

@fritsch I'm sorry for this off topic, I mentioned these two issues alongside with the "\" issue in another topic and the "\" issue got solved, but about these ones I do not know if they were taken care of or not and I don't believe I'm able to test them on my computer on a virtual machine, do you know if they were addressed?

[fritsch]

Kodi is an OpenGL application, from the looks clearly your GPU drivers go insane after resuming. Upgrade kernel to 4.11 and retry.

Edit: For completeness, just tested on my T440s with intel gpu and even Unity running -> works perfectly fine.

[pemartins]

I really don't think it would be a good idea to upgrade to a kernel that my OS doesn't support yet just to test if that bug in Kodi 17.x/18 still happens on it or not, probably something would get broken. In Kodi 16.1 there's no such an issue so probably it has more to do with some change made in Kodi 17.x then the kernel version. Also it doesn't happen with any other application beside Kodi 17.x/18.
And testing it on a VM probably wouldn't be a way to get proper results because it would be ran inside a VM and the behavior of resuming would not be the same as it would manly affect the VM first, I believe.

Btw were you referring to both issues (shade/iconify and OS resuming) or just OS resuming?

[pemartins]

Getting back to the issue of this thread, I just tested the latest nightly and "\" is not remembering the window's place. It's remembering the size but not the place where the window was before going fullscreen.
For what I remember I believe both things were working in a previously nightly I tested and now only the size is kept.
Using Alt+F11 all works as expected.

[FernetMenta]

Getting back to the issue of this thread, I just tested the latest nightly and "\" is not remembering the window's place. It's remembering the size but not the place where the window was before going fullscreen.

That has never been the case. Kodi has always created the window with top left corner to the top left of the root window.

[FernetMenta]

Kodi is an OpenGL application, from the looks clearly your GPU drivers go insane after resuming. Upgrade kernel to 4.11 and retry.

Edit: For completeness, just tested on my T440s with intel gpu and even Unity running -> works perfectly fine.

I don't think this is necessarily a driver issue. More likely that Kodi works by chance on most systems. Textures and texture cache should be refreshed on resume.

[yasij]

Kodi is an OpenGL application, from the looks clearly your GPU drivers go insane after resuming. Upgrade kernel to 4.11 and retry.

Edit: For completeness, just tested on my T440s with intel gpu and even Unity running -> works perfectly fine.

I don't think this is necessarily a driver issue. More likely that Kodi works by chance on most systems. Textures and texture cache should be refreshed on resume.

There was a long standing KDE bug for a similar issue on resume: https://bugs.kde.org/show_bug.cgi?id=344326 . The nvidia driver can evict video memory on suspend/resume. It was just recently fixed in KDE 5.10.3 with a workaround using the GLX_NV_robustness_video_memory_purge extension.

[pemartins]

That has never been the case. Kodi has always created the window with top left corner to the top left of the root window.

Thank you very much for the info. In fact Kodi 16.1 has the same behavior but I could swear that I remember that nightly I tested being remembering the window's place also, which was indeed very handy in my personal opinion.
So I'll leave this in form of a request then, to instead of the window going to a predefined place that is goes back to the place it was before going fullscreen.