Opened 16 years ago
Closed 16 years ago
Last modified 16 years ago
#4738 closed defect (fixed)
using wrong desktop for determine size for Dual-Head (no xinerama) config
Reported by: | Owned by: | Nigel | |
---|---|---|---|
Priority: | major | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
starting mythfrontend on second head results in using desktop dimensions from first head.
sample output: 2008-02-22 13:39:37.939 Total desktop dim: 1280x720, with 1 screen[s]. 2008-02-22 13:39:37.941 Xinerama screen 1 was specified, but only 1 available, so using screen 0. 2008-02-22 13:39:37.941 Connected to database 'mythconverg' at host: localhost 2008-02-22 13:39:37.944 Using screen 0, 1920x1200 at 0,0
Attachments (2)
Change History (19)
Changed 16 years ago by
Attachment: | patch_xinerama_bug.diff added |
---|
comment:1 Changed 16 years ago by
Owner: | changed from Isaac Richards to Nigel |
---|---|
Status: | new → accepted |
Thanks for the patch, Markus. It will fix the problem on Linux, but it will output a confusing "Using all screens" message, and I should test on Mac OS too. Leave it with me for a few days, I might need you to test my final checkin?
Changed 16 years ago by
Attachment: | dual-head.patch added |
---|
svn diff libs/libmyth/mythcontext.cpp programs/mythfrontend/globalsettings.cpp >/dual-head.patch
comment:3 follow-up: 6 Changed 16 years ago by
Markus, your patch was safe on Mac OS, but on Linux non-Xinerama setups, it would cause all monitors to always be used. I suspect that some users might only want the choice to only use first monitor.
My patch enables the Settings->Appearance->"Xinerama screen", so that you can set "All", but should default to the current behavior if you don't set that.
comment:4 Changed 16 years ago by
What did you mean with a non-xinerama setup? I'm think i use such a setup: dual-head with nvidia (no twinview, no xinerama). GetNumberOfXineramaScreens?() results to 0 for my setup and it works fine here with my patch (tested with -display :0.0 and -display :0.1)
Did you mean a twinview setup?
I will try your patch this evening (CET).
comment:5 Changed 16 years ago by
On X11 GetNumberOfXineramaScreens?() should return 0 if the Xinerama extension is not available, and 1,2,3,etc.. if it is.. If the function returns 0 or 1 we should be trust the screen sizes (pixels and mm) and aspect ratios (pixel and physical) returned by the X11 server.
comment:6 Changed 16 years ago by
Replying to anonymous:
My patch enables the Settings->Appearance->"Xinerama screen", so that you can set "All", but should default to the current behavior if you don't set that.
your patch works fine here, for dual-head and twinview/xinerama config too.
Only one thing i don't like, if you change from a xinerama-setup on second head (XineramaScreen? db-value = 1) to a dual-head (-display :0.1) you will got wrong size (taken from first). Perhaps it was better to check if xinerama was disabled and then to not use the db-value but desktop->primaryScreen(). This way you don't bother users which change sometimes their desktop-layout.
comment:7 Changed 16 years ago by
Glad it worked. Thanks for testing, Markus.
Ideally we would use the XineramaScreen? DB value and automatically select the second X display (i.e. eliminate the need for using 'mythfrontend -display 0:N'), but I haven't worked out a way to do that yet). Will move this discussion to the mailing list.
comment:8 Changed 16 years ago by
comment:9 Changed 16 years ago by
comment:10 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
I still haven't tested a Linux multi-head setup, so I don't know if changing the "Xinerama Screen" setting will get around the problem Markus mentioned, but I have had no negative feedback to this patch, so it is now in there.
comment:11 Changed 16 years ago by
I can confirm the bug.
Using the xinerama settings for a dual head setup is confusing, especially selecting "all" for using the current screen.
My dualhead setup was working before [16369].
comment:12 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → new |
Finally built a dual-head system. Now understand the problem - the Xinerama screen selector needed to use desktop()->numScreens() instead of GetNumberOfXineramaScreens?().
I was hoping that, I could somehow use the non-primary display in the absence of a '-display :0.1' argument (i.e. have the XineramaScreen? setting determine the primary screen). After a lot of stuffing around, it looks like the qApp is firmly anchored to the display it was started on, and thus using the Xinerama database settings is pointless. I will commit a fix soon.
comment:13 Changed 16 years ago by
Status: | new → accepted |
---|
comment:14 Changed 16 years ago by
comment:15 Changed 16 years ago by
comment:16 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
(In [16812]) 1) Work around Twinview, non-Xinerama bug, using simple check by Markus Schulz. Basically, desktop->numScreens() is returning 1, which caused the bounds check to fail on -display :0.1. Closes #4738 (for good, I hope :-) 2) On platforms which have Xinerama, but only one active screen, ignore user screen preference database setting. Maybe only problem on OS X?
comment:17 Changed 16 years ago by
(In [16813]) 1) Work around Twinview, non-Xinerama bug, using simple check by Markus Schulz. Basically, desktop->numScreens() is returning 1, which caused the bounds check to fail on -display :0.1. See #4738 2) On platforms which have Xinerama, but only one active screen, ignore the user screen preference database setting. Maybe only a problem on OS X?
patch