tuxmath-devel

[Tuxmath-devel] Fullscreen issues

[Tim H. <ho...@wu...>]

Hi Brendan, David, et al,

I was seeing some unexplained X lockups related to fullscreen, and I finally 
traced the issue down. On my machine (ThinkPad T60), my two 
highest-resolution modes are 1400x1050 and 1280x1024. At work, I plug into a 
monitor with maximum resolution 1280x1024, so I often run my desktop at that 
resolution.

After some head-scratching, here's what I've determined:
1. If I run my laptop (using its screen only, not connected to the external 
monitor) at 1400x1050 mode, TuxMath fullscreen works fine.
2. If I have re-started X at work, plugged into the monitor and running at 
1280x1024, TuxMath fullscreen works fine.
3. If I'm running without the monitor, but running X & my desktop at 1280x1024 
anyway, then I was getting X lockups on fullscreen but not --windowed.

It turns out that the problem in situation #3 is that SDL_ListModes would 
still list 1400x1050 as the first entry, even though X was running at 
1280x1024. TuxMath tried to set 1400x1050 as the resolution, but this led to 
an X lockup (fixed by Ctrl-Alt-Backspace).

With some random experimentation, I finally figured out that the lockup can at 
least be avoided by _not_ using atexit() to register the cleanup 
function---then tuxmath "just" crashes (whew). So I replaced the atexit() 
registration of cleanup back to what it used to be, a direct call to cleanup. 
(Weird---I thought that's what atexit is supposed to be for, handling 
unexpected problems...) I've committed that change.

Now X doesn't lock up during a crash, instead I get the following output on 
the console:
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  134 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x86
  Serial number of failed request:  109
  Current serial number in output stream:  111

Can anyone else verify that this is a problem, or is it just my combination of 
hardware/drivers? (I've tried both fbdev & fglrx). Does anyone know how one 
can determine the desktop's current resolution, so that we can avoid trying 
to set a too-high resolution? Or is this an SDL bug?

Best,
--Tim

Re: [Tuxmath-devel] Fullscreen issues

[B. L. <che...@gm...>]

Interesting. I'm not at all well-versed in X, but for what it's worth
I played around with settings and got an extended dual screen
up--1280x800 on the laptop and 1280x1024 on the external. When I ran
the game, SDL detected an "optimal" resolution of 2560x1024! It ran
fine, too, besides the fact that the 1280x224 bottom-left portion of
the screen wasn't being displayed at all :) The only other display I
could get to work was the external forced to 800x600, which also ran
the game fine.

"3. If I'm running without the monitor, but running X & my desktop at 1280x1024
anyway, then I was getting X lockups on fullscreen but not --windowed."

Hmmm. X thinks that 1280x1024 is where it's at, but SDL_ListModes gets
its information from hardware and knows better. So when SDL queries,
it bypasses X, but when it tries to use that mode, it does go through
X somehow. Out of curiosity, are you getting a hardware surface? Mine
is in software.

Re: [Tuxmath-devel] Fullscreen issues

[Tim H. <ho...@wu...>]

Hi Brendan,

On Wednesday 18 June 2008, you wrote:
> Interesting. I'm not at all well-versed in X, but for what it's worth
> I played around with settings and got an extended dual screen
> up--1280x800 on the laptop and 1280x1024 on the external. When I ran
> the game, SDL detected an "optimal" resolution of 2560x1024! It ran
> fine, too, besides the fact that the 1280x224 bottom-left portion of
> the screen wasn't being displayed at all :) The only other display I
> could get to work was the external forced to 800x600, which also ran
> the game fine.

You probably have already done all this (or whatever similar steps are 
appropriate for your system) already, but just in case.... Here's what I did 
on my system (Kubuntu Hardy):
1. Go to "System Settings"
2. Choose Monitor & Display
3. Make the screen size smaller & click OK.

It's possible that it's a driver-specific thing, and that my ATI card&driver 
will behave differently than another system.

>
> "3. If I'm running without the monitor, but running X & my desktop at
> 1280x1024 anyway, then I was getting X lockups on fullscreen but not
> --windowed."
>
> Hmmm. X thinks that 1280x1024 is where it's at, but SDL_ListModes gets
> its information from hardware and knows better. So when SDL queries,
> it bypasses X, but when it tries to use that mode, it does go through
> X somehow. Out of curiosity, are you getting a hardware surface? Mine
> is in software.

Same here.

--Tim

Re: [Tuxmath-devel] Fullscreen issues

[B. L. <che...@gm...>]

Duh, of course. I was so busy playing around with xorg.conf, I didn't
even think to use the GUI control. Same issue:

Optimal resolution is 1280x800
X Error of failed request:  BadValue (integer parameter out of range
for operation)
  Major opcode of failed request:  134 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x55
  Serial number of failed request:  115
  Current serial number in output stream:  117

X seems to recover for me, though. If SDL had any way to query the
system rather than hardware, I'd have thought it would be
SDL_ListModes. It even passes SDL_VideoModeOK(); it's the actual
request that effects a crash and burn. I can't think of any way around
it other than using another API to find out what X is running at.
Perhaps we ought to test it on Windows and Mac to see if there are
similar problems.

Brendan

On Wed, Jun 18, 2008 at 5:56 PM, Tim Holy <ho...@wu...> wrote:
> Hi Brendan,
>
> On Wednesday 18 June 2008, you wrote:
>> Interesting. I'm not at all well-versed in X, but for what it's worth
>> I played around with settings and got an extended dual screen
>> up--1280x800 on the laptop and 1280x1024 on the external. When I ran
>> the game, SDL detected an "optimal" resolution of 2560x1024! It ran
>> fine, too, besides the fact that the 1280x224 bottom-left portion of
>> the screen wasn't being displayed at all :) The only other display I
>> could get to work was the external forced to 800x600, which also ran
>> the game fine.
>
> You probably have already done all this (or whatever similar steps are
> appropriate for your system) already, but just in case.... Here's what I did
> on my system (Kubuntu Hardy):
> 1. Go to "System Settings"
> 2. Choose Monitor & Display
> 3. Make the screen size smaller & click OK.
>
> It's possible that it's a driver-specific thing, and that my ATI card&driver
> will behave differently than another system.
>
>>
>> "3. If I'm running without the monitor, but running X & my desktop at
>> 1280x1024 anyway, then I was getting X lockups on fullscreen but not
>> --windowed."
>>
>> Hmmm. X thinks that 1280x1024 is where it's at, but SDL_ListModes gets
>> its information from hardware and knows better. So when SDL queries,
>> it bypasses X, but when it tries to use that mode, it does go through
>> X somehow. Out of curiosity, are you getting a hardware surface? Mine
>> is in software.
>
> Same here.
>
> --Tim
>

Re: [Tuxmath-devel] Fullscreen issues

[David B. <dav...@gm...>]

Hi,

 Perhaps we ought to test it on Windows and Mac to see if there are
> similar problems.


I've built it for Windows and so far it's worked fine.  I have a
work-supplied Dell Windows laptop with a docking station setup.  The native
resolution of the laptop is 1280x800, and the docking setup has a 1280x1024
flat panel.  With the laptop alone, tuxmath runs fullscreen at 1280x800 even
if I turn the resolution down to 800x600, and it goes back properly to
1280x800 on exit.  With the machine docked, it correctly uses 1280x1024 on
the desktop display.  The laptop's monitor is not visible when it is docked.

On my Debian machine, I get the same problem you guys have noted if I use
KDE's gui widget to set the resolution down to 800x600 before starting
tuxmath (in my case, the display is frozen, but I can fix things up by
switching to another TTY and killing the tuxmath process).  fwiw, if I use
Ctrl-Alt-+ to change the "resolution", tuxmath -f works fine.

I wonder if the difference is that X always tries to use the highest
resolution listed in Xorg.conf, if the monitor will support it - in other
words, when we set it to something lower, we also forbid it to use anything
higher.

At any rate, this looks like something to post to the SDL mailing list.  I
need to re-subscribe since I changed my email, anyway, so I'll post it
tomorrow.

David

David