+- 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)
- WiSo - 2008-11-19
CapnBry Wrote: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:
I'm with you and just raised the question since I saw some user requests for this feature.
- DesG - 2008-11-19
First off,a big thanks to everyone for looking at these issues!
CapnBry Wrote: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..
I know of at least one situaution where a single monitor is used, but the mouse can roam off the screen. If someone is using a software K(V)M such as Synergy. If the mouse isn't captured anymore, it isn't a problem, but just thought I would mention it in case anyone decides to capture the mouse again in single screen mode.
CapnBry Wrote:2) Multi monitor XBMC fullscreen spanning all monitors - this is just a bigger version of single monitor fullscreen..
With Nvidia, the spanned setup lists only one display, can't be sure don't use that setup anymore.
CapnBry Wrote: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.
This is the use case that the majority of the people on this thread are looking for. I currently run VLC or WMP-classic on my secondary monitor, and I would love to use XBMC there instead. (not enough to install .net tho
Cheers, Des.
- davilla - 2008-11-19
These are all good discussion points. The only concern I have is the focus on resolution. The current code focus is g_settings.m_ResInfo with m_Resolution setting the index with g_settings.m_LookAndFeelResolution causing problems when it can. What the hell is m_LookAndFeelResolution anyway and why does it not track m_Resolution? :
) And g_videoConfig. m_ResInfo is also present which adds to the confusion.m_ResInfo has no display device info and multiple display support appears as appended resolutions which mean one as to parse it to figure out what is fullscreen on display N. Just did this on OSX to fix the calibration/overscan bug that occurred when multiple display was fixed.
If we restructure to
curdisplay (current and points to display 1, or display 2)
display 1
fullscreen setting
a) fullscreen keep display resolution
b) fullscreen change display resolution
windowed setting
display 2
fullscreen setting
a) fullscreen keep display resolution
b) fullscreen change display resolution
windowed setting
Then have gui settings (SDL, probe or guess) fill this out, then the rest of xbmc code does not have to fiddle around with what's m_Resolution and keeping m_LookAndFeelResolution in sync. It just references curdisplay.
Multiple display spanning is a virtual display device (and that's going to get real messy because of platform dependencies).
Do we really have to save a list of all resolutions possible in g_settings.m_ResInfo or is only the current fullscreen/windowed required? The only reason I can think of is display change to content resolution where one would want to preset video calibration for various sizes.
Doing display change to content resolution is really a fullscreen option. This option will have to verify using display info that the display can really accept this change or bad things can happen.
And
Monitor: Dell 2001FPW (Display 0)
will only work if the monitor name can be retrieved and you can't depend on this.
Monitor: Display 0 (Dell 2001FPW) is better.
Other issues, can display numbering be consistent across reboots. The main display will always be Display 0 (or some other naming), but possible other displays retain the order? Remember platform differences so one of the first things to investigate is how does the platform OS signify consistant display order and can displays be dynamically (plug it in an it starts working) added or removed (OSX can do this, not sure of Windows or Linux).
And fullscreen launch on a specific display/monitor without gui setup.
Just throwing some things out for discussion.
- jmarshall - 2008-11-19
The above sounds fine to me in terms of organisation. A list of displays, and information on the resolution to use for that display is all we really need. And yes, we need to isolate this in the code so that we're not referencing it from elsewhere directly.
I see little point in having xbmc switch to a separate display for video playback, but I certainly see a use in switching to a different refresh rate for playback (eg 24p).
Cheers,
Jonathan
- CapnBry - 2008-11-19
WiSo Wrote:I'm with you and just raised the question since I saw some user requests for this feature.Oh I hope I didn't sound snippy about it! I was just expanding on your comment.
davilla Wrote:display 1Can you clarify what you mean by this a little? You mean like this?
fullscreen setting
a) fullscreen keep display resolution
b) fullscreen change display resolution
windowed setting
Code:
struct displayInfo {
int displayNumber;
char *displayName;
RESOLUTION_INFO fullscreenRes;
bool fullscreenChangesResolution;
RESOLUTION_INFO windowedRes;
}- jmarshall - 2008-11-19
I believe that's the case, yes. Do we need a separate windowedRes per display, or can we reuse a single one? Essentially it's just storing the window size, right?
- CapnBry - 2008-11-19
Oh good point, yeah only one windowedRes is needed and it would probably help to store the last position it was at too.
- davilla - 2008-11-19
CapnBry Wrote:Oh I hope I didn't sound snippy about it! I was just expanding on your comment.
Can you clarify what you mean by this a little? You mean like this?Other than that clarification, I'm liking these ideas so far.Code:struct displayInfo {
int displayNumber;
char *displayName;
RESOLUTION_INFO fullscreenRes;
bool fullscreenChangesResolution;
RESOLUTION_INFO windowedRes;
}
No harm, no foul, I have thick skin :
Yes something like that. On big changes like this, I tend to think a lot before doing any coding. Sort of lay out the ground work make some structures/classes and look for holes or problems like race conditions/threading issues. Basic idea is to make access by other parts of XBMC real easy and quick (most do not care if full or windowed, they just want the current size or overscan info) and put the grunt work (and platform ifdefs) in one or two places.
Folding into linuxport is going to by tricky since this touches so many places and it might be better to branch linuxport, bring up single display, change the gui settings to support multiple display, bring up multiple displays. If we have done everything corectly, that last part will just work
Then merge back into linuxport. That way, these changes don't cause problems with dev work in other areas while any issues are hunted down and resolved.
- jmarshall - 2008-11-19
Agreed - a separate branch is the way to go.
- CapnBry - 2008-11-19
I volunteer to handle the win32 probing, resolution switching, and positioning code if someone else will lead the way by getting started on another platform. Also assuming I'm not stepping on WiSo or anyone else's toes.
- jmarshall - 2008-11-19
Go for it - I'm sure WiSo's toes won't mind
- WiSo - 2008-11-19
CapnBry Wrote:Also assuming I'm not stepping on WiSo or anyone else's toes.
Please go ahead
You already lost me some posts before and I appreciate any help
- davilla - 2008-11-20
linuxport branched to multidisplay, lets break it :
)I can't start having fun until later (still at work)
xbmclaunch working only on first run - paseant - 2008-11-21
Hi. xbmclaunch is not working well for me. I have tried everything suggested in this thread but the problem is always the same:
- first time I run xbmclaunch after a reboot works perfectly.
- second run of xbmclaunch results in the problem commented before by oscarliu ("XBMC seems to launch on the primary monitor for a flash second and then minimize to the bottom bar. After clicking "move", the secondary monitor becomes all white. I then press ESC and XBMC appears finally on the secondary")
- third run do nothing. It is also imposible to run xbmc.exe.
After some indeterminate time it is sometimes posible to launch xbmc.exe and then xbmclaunch works ok one more time before failing again as before. Restarting repeats cycle.
This is on Vista SP1 with an nvidia 8600GT. Hope my english is not too nasty.
- WiSo - 2008-11-23
@CapnBry: You might wanna have a look here -> http://forum.xbmc.org/showthread.php?tid=40423