[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Display set_mode FULLSCREEN hang
To kill a hung full-screen program use CTRL+ALT+F1 to switch to a
console, and kill it from the command-line. Then CTRL+ALT+F7 to switch
back to X
---
James Paige
On Mon, May 11, 2009 at 02:47:15PM -0700, Yanom Mobis wrote:
> I never trust fullscreen, because if your app is windowed and it hangs, you
> can pull up a terminal emulator and shut the app down with xkill. (At least
> on Linux/UNIX)
>
> --- On Mon, 5/11/09, Rene Dudfield <renesd@xxxxxxxxx> wrote:
>
> From: Rene Dudfield <renesd@xxxxxxxxx>
> Subject: Re: [pygame] Display set_mode FULLSCREEN hang
> To: pygame-users@xxxxxxxx
> Date: Monday, May 11, 2009, 12:31 AM
>
> hi,
>
> ah. VideoCapture uses directx to do its thing... and as you are on XP, it
> is likely choosing directx video driver. So that's probably why the two
> are mixing weirdly.
>
> thanks for reporting back with what you found out.
>
> I'm not sure if you can select a refresh rate (yet).
> From the SDL release notes... "The default fullscreen refresh rate has
> been increased to match the desktop refresh rate, when using equivalent
> resolutions. A full API for querying and selecting refresh rates is
> planned for SDL 1.3"
>
> Of course, if you want to go and implement it yourself... you could always
> patch SDL to do your bidding.
>
> However... with LCD screens, the like the native resolution... so you
> could choose the desktop resolution and use pygame.transform.scale to
> draw. That should give you the refresh rate you want. So that is one
> possible work-around.
>
> cu,
>
> On Mon, May 11, 2009 at 2:48 PM, Adam Li <adamli@xxxxxxxxxxxxxx> wrote:
>
> It seems that the pygame initialization has to be before the
> VideoCapture initialization. If the VideoCapture camera is created
> first, the pygame.display.set_mode((0,0), pgame.FULLSCREEN) will hang.
>
> By the way, how can I specify the refresh rate of the display? For me,
> pygame selects a 70Hz refresh frequency, but I prefers 60Hz.
>
> Thanks,
>
> Adam
>
> Rene Dudfield wrote:
>
> ah ok.
>
> It would be good to know the failing order... so other people can work
> around it... or maybe we can fix it.
>
> cu,
>
> On Mon, May 11, 2009 at 11:25 AM, Adam Li <adamli@xxxxxxxxxxxxxx
> <mailto:adamli@xxxxxxxxxxxxxx>> wrote:
>
> Hi Rene,
>
> Thanks for your reply. The little Atom board (it is a custom-built
> board) is running standard Windows XP.
>
> pygame.display.list_modes() returns:
>
> [(1280, 1024), (1280, 1024), (1280, 960), (1280, 768), (1280,
> 720), (1152, 864), (1024, 768), (960, 540), (800, 600), (800,
> 480), (720, 480), (640, 480)]
>
> The LCD is 1280x1024. I have tried to call set_mode with (0, 0),
> (1280, 1024), and (640, 480) and all getting the same problem.
>
> On a plus note, after a lot of tried this afternoon, I was able to
> get it to work by shuffling the order of the initialization code
> between pygame and other modules I am loading. So maybe the
> problem is with the conflicting access to resources, or something.
>
> I am using pygame, PIL, and a webcam module called VideoCapture.
> Hope it helps.
>
> Thanks,
>
> Adam
>
> Rene Dudfield wrote:
>
> hi,
>
> definitely sounds like a bug... but most likely in the X.
>
> Have you used list_modes first?
>
> http://www.pygame.org/docs/ref/display.html#pygame.display.list_modes
>
> What does your little computer say are available?
>
> cu,
>
> On Mon, May 11, 2009 at 8:47 AM, Adam Li
> <adamli@xxxxxxxxxxxxxx <mailto:adamli@xxxxxxxxxxxxxx>
> <mailto:adamli@xxxxxxxxxxxxxx <mailto:adamli@xxxxxxxxxxxxxx>>>
> wrote:
>
> Hi there,
>
> Just wrote small code to test different screen mode. It
> works well
> on my desktop, but when I moved it to an Atom-based
> computer,
> there is a problem.
>
> The code appears to hang when I set_mode with FULLSCREEN.
> Again,
> the same code works without problem on my desktop, but not
> on this
> small Atom-based computer. Other modes works fine on both
> computers as well, as long as I don't set the FULLSCREEN
> flag.
>
> The display adapter is "Intel US15 Embedded Graphics Chipset
> Function 0".
>
> Any idea? Could it be a bug?
>
> Thanks,
>
> Adam