+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Windows (https://forum.kodi.tv/forumdisplay.php?fid=59)
+---- Thread: Problems going to windowed mode (/showthread.php?tid=37413)
- DesG - 2008-11-18
xbs08 Wrote:Des: Don't forget about releasing the mouse to the other monitor, thats critical too.
Disable the mouse in xbmc.
Then how can I select anything ?
Cheers, Des.
- ashlar - 2008-11-18
CapnBry Wrote:It is not broken, it is by design I believe as in the code explicitly forbids windowed "custom" resolutions. Custom resolutions are any non-TV resolutions detected at startup (the previous startup but that's another issue). I changed (#5256) that but it was too close to Atlantis release date so it was pushed to the next milestone. It went into SVN r16218 today though, but it still needs a lot of checking out and probably some tweaks.Could this be the solution to this: http://trac.xbmc.org/ticket/5307 ?
Anyway, my eventual goal is to have it launch to any monitor, any resolution and be able to toggle fullscreen/windowed but we're babystepping it in piece by piece to make sure nothing else breaks.
Could I launch in windowed mode (removing the -fs switch) and still run at my desktop resolution, keeping the desktop refresh rate?
- WiSo - 2008-11-18
Yes but still with the window border as usual.
I think we have to think off a possibility to implement the border less maximized window as option, either via hotkey or as a choose able replacement for fullscreen.
have to discuss this with jmarshall and CapnBryn.
- ashlar - 2008-11-18
WiSo Wrote:Yes but still with the window border as usual.Right, didn't think of this...
Quote:I think we have to think off a possibility to implement the border less maximized window as option, either via hotkey or as a choose able replacement for fullscreen.That would be really useful (for me, at least, but I suppose for others as well, as more and more TVs support 24fps).
have to discuss this with jmarshall and CapnBryn.
- jmarshall - 2008-11-18
Implementing different refresh rates in fullscreen might be a better solution, primarily as I believe that vsync is touch and go when in windowed mode on many drivers (well, more touch and go than it is in fullscreen!)
And windowed mode should, ofcourse, be resizable in the usual way that windows are!
- xbs08 - 2008-11-18
DesG Wrote:Then how can I select anything ?
Cheers, Des.
With the remote? or keyboard?
- WiSo - 2008-11-18
jmarshall Wrote:Implementing different refresh rates in fullscreen might be a better solution, primarily as I believe that vsync is touch and go when in windowed mode on many drivers (well, more touch and go than it is in fullscreen!)
And windowed mode should, ofcourse, be resizable in the usual way that windows are!
Not sure if we wanna hack SDL to repair vsync in fullscreen. I would see this also only as an option to normal fullscreen.
But still, having a maximized window might work better on multi monitor setups (move mouse out of XBMC and other side effects fullscreen may have on the other screen).
But as usual I'm open for suggestions
- CapnBry - 2008-11-19
WiSo Wrote:Yes but still with the window border as usual.I was under the impression that fullscreen now is actually maximized borderless with resolution change. I haven't looked in the past couple weeks though, so don't take that as truth. I'll pull updated trunk tonight and have a look if I have a chance.
I think we have to think off a possibility to implement the border less maximized window as option, either via hotkey or as a choose able replacement for fullscreen.
have to discuss this with jmarshall and CapnBry.
EDIT: Conflicts in my source tree? You bastards!
- davilla - 2008-11-19
I think we devs need to come up with a roadmap outline of exactly how the display resolution and going from windowed to fullscreen should be handled (including multiple displays and correct saving/restore of calibration settings). Then we make the code do what we have spec'd.
Right now, XBox, Linux, Windows and OSX all have their own individual quirks regarding display resolution and some platforms have total different results when going from a windowed to fullscreen. Throw in multiple displays, and it's coding ifdefs all over the place.
And I for one am going to get pissed if when going from windowed to fullscreen the actual display resolution changes and all my desktop icons are re-ordered from the way I had them.
- SliM3 - 2008-11-19
Select the desired resolution in the XBMC display settings - don't use 'auto'.
- harlekin - 2008-11-19
If I might add, resolution and Hz (refresh) rate.
Just for the purpose of getting the idea out, it also would be nice to have an option where XBMC would change the full screen resolution and framerate of video/movie content to the appropriate standardized one, once it starts, so f.e. if you choose a 720p 60hz video, to 1280x720(/768)@60Hz, if you choose a 720p 24hz movie to 1280x720/768)@24Hz, if you choose to play a 1080p 24hz movie to 1920x1080@24p, if you choose a SD movie to either PAL60, or NTSC, and so on; Allthough this certainly is not easy to get automated (and would almost defeat the purpose of the integrated zoom modes, on second thought, maybe leave it to be an easy reachable manual selection option..
) , it might ultimatively be what the market (for the lack of a better term) demands.HDTVs nowadays are heavy geared towards image processing and most likely will provide a better upscaling and movement performance result, than XBMC on bilinear and 60Hz.
- davilla - 2008-11-19
SliM3 Wrote:Select the desired resolution in the XBMC display settings - don't use 'auto'.
Missing the point which is across the three (four counting xbox), the behavior of the resolution setting and what happens when going fullscreen is currently platform dependent. This makes tech support and documentation much harder and is generally more confusing to all. This need to have a unified behavior and setup across all platforms.
- jmarshall - 2008-11-19
davilla: Agreed. To start things rolling, how about this:
1. We have a windowed mode which is resolution independent, and simply runs in a resizable window. Skin is dynamically reloaded as necessary after a change based on window size and aspect. Does linux do this already perhaps?
2. We have a fullscreen mode which runs fullscreen using:
a) The monitor the user wishes to have it on, and
b) The resolution the user wishes to have. This can be the desktop res if they like.
3. Video playback resolution may be specified separately if it makes sense. IMO the only thing that really makes sense there is to change the refresh rate to best match the source framerate, but keep the resolution the same. I'm not sure that there's a valid case for running different resolutions for playback and UI.
Thoughts?
Cheers,
Jonathan
- WiSo - 2008-11-19
Agreed.
There's still the question if we can get the mouse out of XBMC in fullscreen and multi monitor setup.
- CapnBry - 2008-11-19
Completely agree with davilla. The original XBOX hardware and sinple-purpose nature of the device made this a pretty simple option but it really has gotten complex as we generalize it to a more multipurpose use.
The resolution configuration in XBMC linuxbranch has a lot of discussion across many threads in this forum, and I'm fully behind forming a consensus on a new design. I think Johnathan's got a good start there. The options should look more like:
Windowed: (checkbox, if windowed the options below are grayed)
Monitor: Dell 2001FPW (Display 0)
Resolution: 1680x1050@60Hz
The question then becomes how the resolution options are filled. Currently they come fully from SDL's probe. Are there any situations where probing would not be sufficient for allowing the user the resolution they want? Does probing provide too many options?
EDIT: So my point being we should remove mouse capture in fullscreen from every platform.
I can also see the need for video playback at different settings. However I can see the case for people wanting to run both at the video's resolution and refresh. This is where the configuration can become a nightmare.
WiSo Wrote:Agreed.Under windows I know it doesn't capture the mouse any more. I can't imagine any reason anyone would want their mouse constrained unless there are more cases than this:
There's still the question if we can get the mouse out of XBMC in fullscreen and multi monitor setup.
1) Single monitor fullscreen - mouse doesn't need to be captured. Where else can it go that it needs to be captured. Prevent the mouse from leaving the screen? It's can't leave the screen, at least with existing technology.
2) Multi monitor XBMC fullscreen spanning all monitors - this is just a bigger version of single monitor fullscreen
3) Multi monitor XBMC fullscreen in one monitor - why would a user have multiple active monitors if you're effectively going to prevent input from going to the other? The nature of XBMC as a media playback application also means input focus is rarely needed as the majority of the time is spent playing media, not selecting or controlling it.