This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• Use display modes obtained via Xinerama (xinerama.diff, text/plain, 2011-10-17 10:08:05 +0000, 928 bytes)
• Patch to fix Xinerama version query. (SDL-xinerama-version-RYAN1.diff, text/plain, 2011-10-24 12:36:59 +0000, 1478 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2011-10-17 10:08:05 +0000, Gabriel Jacobo wrote:

Created attachment 716
Use display modes obtained via Xinerama

I'm using Ubuntu 11.04, with propietary Nvidia drivers and twinview activated. I have two monitors, at 1920x1200 and 1024x768 each. As such, xrandr reports a single desktop of 2144x1200. When I try to create a full screen window, I get the window created properly in the first monitor, but the size of the window is not 1920x1200 as you'd expect, but 2144x1200.

A couple of sidenotes:
If I configure xorg.conf with NoTwinviewXineramaInfo=false, I get the window stretched across BOTH monitors, with a size of 2144x1200.
If I add an additional metamode to xorg.conf where one monitor is disabled, then SDL does change the mode and creates a window of 1920x1200 with the secondary monitor disabled.

However, this is not what I expect should happen...I think I should get a fullscreen window in the desired monitor without having to do any of that. It turns out that SDL already fetches the Xinerama information the Nvidia driver provides, but then it does a calculation based on the Xinerama major and minor version (which in my case are set to zero), which causes it to ignore said information...which except for this two numbers being zero is completely valid. The attached patch solves the problem.
Applying this patch makes the fullscreen windows under X11 with Nvidia Twinview behave as one would expect, my only hesitation would be what happens under an ATI system or some other system that provides Xinerama (probably nothing bad if those Xinerama major and minor version numbers are being set properly in those drivers).

On 2011-10-24 12:23:28 +0000, Ryan C. Gordon wrote:

(In reply to comment # 0)

version (which in my case are set to zero), which causes it to ignore said
information...which except for this two numbers being zero is completely valid.

This number is zero because we're calling the wrong Xinerama API to query the version.

We call XineramaQueryExtension(), which is giving us the event/error bases, which are legitimately zero in this case as Xinerama doesn't generate events or errors, I think.

We should be calling XineramaQueryVersion() instead.

--ryan.

On 2011-10-24 12:25:39 +0000, Ryan C. Gordon wrote:

Also: as an administrative note: Please set a username in your $HOME/.hgrc file, like this:

[ui]
username=Ryan C. Gordon icculus@icculus.org

...it makes it hard to import patches or pull from your clone if the username isn't set, because it makes our revision history ugly (uglier? :) ).

--ryan.

On 2011-10-24 12:35:11 +0000, Gabriel Jacobo wrote:

I didn't know it was a problem for patches submitted through here as well, I'll update my settings ASAP.

As to the actual bug, I'll try XineramaQueryVersion and see what I get.

On 2011-10-24 12:36:59 +0000, Ryan C. Gordon wrote:

Created attachment 719
Patch to fix Xinerama version query.

Attaching attempt to fix this bug by correcting Xinerama API use.

I don't have a Xinerama setup here; can you revert your patch and try this one? I'll push it if you can confirm it works.

Thanks,
--ryan.

On 2011-10-24 12:40:44 +0000, Ryan C. Gordon wrote:

(In reply to comment # 3)

I didn't know it was a problem for patches submitted through here as well, I'll
update my settings ASAP.

Yeah, the output from "hg export" can be used to pull in the patch as if it were a real commit and not just changes to the working copy. "hg import" parses all the '#' lines at the start of the patch for the metadata. :)

Thanks!

--ryan.

On 2011-10-24 16:30:49 +0000, Gabriel Jacobo wrote:

I can confirm your patch fixes the problem.

On 2011-10-24 19:51:24 +0000, Ryan C. Gordon wrote:

This is now hg changeset 56185b574d61!

--ryan.