Description
Issue №1664 opened by mess-maker at 2020-04-24 15:16:25
Using chromebook
vscode on crostini debian buster (the linux container)
python 3.7.3
pygame 1.9.6 the pygame windows stay black and flicker with defined backgroud color (not usable)
when using pygame (2.0.0.dev6) it work OK in windowed mode (no flickering) run a bit slow but OK
when trying to set in full screen mode the app close with this error :
pygame.error: Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface
Related Docs: https://www.pygame.org/docs/ref/display.html# pygame.display.set_mode
Comments
# # illume commented at 2020-04-25 19:30:58
I think this is related to this PR pygame/pygame#1639
# # MyreMylar commented at 2020-05-12 18:46:12
@mess-maker has pygame 2.0.0.dev8 fixed the crash you were experiencing with pygame 2?
# # MyreMylar commented at 2020-05-12 18:49:47
A decent 'what is crosstini' guide for those who (like me) who hadn't heard of it:
https://www.reddit.com/r/Crostini/wiki/getstarted/crostini-setup-guide
# # mess-maker commented at 2020-05-20 08:20:34
hi sorry for the delay
yes pygame 2.0.0 dev 8 is better but still some quirck
for the error message
"pygame.error: Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface"
I don't get it anymore and setting with full screen don't crash instantly as before
I start my game (full screen is set by the command "pygame.display.set_mode((0, 0), pygame.FULLSCREEN")
When starting game, screen flicker with the pygame windows not managing to get on top of others
clicking the screen make it pop on top for a few millisecond then pop back
after some time doing this the windows stay on top and the things runs OK
after many test, sometime it stabilize after 1 or 2 sec sometime it need 20 to 30s
2 others quirks
clicking the close windows cross don't close the windows, I need to kill the process to end it
same with the "q" keyboard key that is set in the program to end the game
work OK in windowed
the windows generated in fullscreen mode is bigger than the actual screen (I dont see the bottom end)
thanks for your work !
# # MyreMylar commented at 2020-05-20 09:28:28
Hmm, just so we are working from the same test code, try this:
import pygame
pygame.display.init()
width, height = pygame.display.Info().current_w, pygame.display.Info().current_h
window_surface = pygame.display.set_mode((width, height), pygame.FULLSCREEN)
running = True
clock = pygame.time.Clock()
while running:
clock.tick(60)
for event in pygame.event.get():
if event.type == pygame.QUIT:
running = False
if event.type == pygame.KEYDOWN and event.key == pygame.K_ESCAPE:
running = False
pygame.display.update()
Which should open a fullscreen, software display with some fairly stable settings (not handling events can cause issues as can running with an uncapped framerate).
# # mess-maker commented at 2020-05-20 10:34:57
hi
testing with your code give same behaviour
I click run in vscode, the screen flicker with the pygame windows appearing breafly. then vanish (don't appear in the task bar)
when i click on the vscode windows that remain on top (clicking in the text editor not the run button)
the screen flicker btw the 2 windows for btw 0.1, to 1 s.
Reapeating this click/flicker process finally get the pygame windows stable on top (need from 5 to 10 click)
on rare occasion click/flicker process crash vscode
one remark
my chromebook is a Dell Inspiron Chromebook 14-7486 with 1920x1080 screen
in chromebook setting the display is set to 90% (for better readability) so equivalent to a 1707x960
the native resolution correspond to 80% setting, 100% give 1536x864
so with my setting of 90% == 1707*960
width, height = pygame.display.Info().current_w, pygame.display.Info().current_h
report a screen of 2128x1200 (that 1920/0.9, 1080/0.9) seems the 90% of chromebook settings are taken into account in reverse
tested with this 3 sets
window_surface = pygame.display.set_mode((width, height), pygame.FULLSCREEN)
window_surface = pygame.display.set_mode((1920, 1080), pygame.FULLSCREEN)
window_surface = pygame.display.set_mode((1707, 960), pygame.FULLSCREEN)
gets same behaviour
with setting at 80% == 1 920x1080
width, height = pygame.display.Info().current_w, pygame.display.Info().current_h
report 2400x1350
here same thing all combination of pygame.display.set don't solve issue
with setting at 100% == 1536x64
width, height = pygame.display.Info().current_w, pygame.display.Info().current_h
report 1920x1080
here same thing all combination of pygame.display.set don't solve issue
last test, if I run the script directly in terminal with vscode not running
screen flicker just 1 or 2 time then stay with terminal on top (but pygame running somewhere in the background, no icon in task bar, not visible by reducing others windows)
here clicking in the terminal don't make the screen flicker again and I can't manage to get pygame on top
if I lauch vscode and click (without running the script again) we get back the previous behavior:
I can get on top the pygame launched via terminal)
# # MyreMylar commented at 2020-05-20 10:58:35
Ok, sounds like the next thing to try is the pygame.SCALED flag. This goes down a different path using hardware rendering - there is currently an active Pull Request for it so behaviour in 2.0.0.dev8 will not be as good as after that gets merged, but it may have some impact now. To activate:
import pygame
pygame.display.init()
width, height = pygame.display.Info().current_w, pygame.display.Info().current_h
window_surface = pygame.display.set_mode((width, height), pygame.FULLSCREEN | pygame.SCALED)
running = True
clock = pygame.time.Clock()
while running:
clock.tick(60)
for event in pygame.event.get():
if event.type == pygame.QUIT:
running = False
if event.type == pygame.KEYDOWN and event.key == pygame.K_ESCAPE:
running = False
pygame.display.update()
# # mess-maker commented at 2020-05-20 11:24:36
fresh start of the chromebook
running this script in vscode
screen goes black as expected (seems flickering are gone)
after 1 sec vscode crash and as pygame
reboot fresh start of the chromebook
running this script from terminal
screen goes black as expected (seems flickering are gone)
after 1 sec crash with this error
pygame 2.0.0.dev8 (SDL 2.0.12, python 3.7.3)
Hello from the pygame community. https://www.pygame.org/contribute.html
XIO: fatal IO error 0 (Success) on X server ":0"
after 505 requests (499 known processed) with 0 events remaining.
# # MyreMylar commented at 2020-05-20 12:14:01
That sounds like this bug:
https://stackoverflow.com/questions/25790890/xio-fatal-io-error-11-caused-by-32-bit-libxcb
# # MyreMylar commented at 2020-05-20 12:17:32
Actually, that error message doesn't make much sense?
XIO: fatal IO error 0 (Success) on X server ":0"
what the heck does that mean?
# # MyreMylar commented at 2020-05-20 12:19:49
Digging around a bit more I see a reference to the problem here in 2003:
# # MyreMylar commented at 2020-05-20 12:30:19
This definitely seems like an SDL2 issue. I wonder if this old C code from that bug will run on your setup:
# include <X11/Xlib.h>
# define MAX_FONTS 1024*16
int * __errno_location(void) {
static int errno;
return &errno;
}
int main() {
char **C;
int num;
Display *display;
char *display_name = NULL;
int i;
if ((display = XOpenDisplay(display_name)) == NULL) {
printf("ME: cannot open display %s\n", XDisplayName(display_name));
exit(-1);
}
C = XListFonts(display,"*",MAX_FONTS,&num);
for (i = 0; i < num;i++) {
printf("%s\n",C[i]);
}
return 0;
}
Compile & run:
$ gcc -o test test.c -I/usr/X11R6/include -L/usr/X11R6/lib -lX11
$ ./test
# # mess-maker commented at 2020-05-20 15:37:31
I getting out of my confort zone lol
so taken your code, added thoose 2 lines because of vscode moaning
`# include <stdio.h>
include <stdlib.h>`
then modified the gcc command like this
gcc -o test -c test.c -I/usr/include -L/usr/lib/x86_64-linux-gnu
because my X11/Xlib.h is in /usr/include/ (same for stdio.h and stdlib.h)
libX11.so is in /usr/lib/x86_64-linux-gnu/
so if I've understood what we are doing here I think my modification are good
Doing so the code compile with no error (my first compilation of C code ;) )
running it i get this
jojo@penguin:~/testpygame$ gcc -o test -c test.c -I/usr/include -L/usr/lib/x86_64-linux-gnu
jojo@penguin:~/testpygame$ sudo chmod +x ./test
jojo@penguin:~/testpygame$ ./test
-bash: ./test: cannot execute binary file: Exec format error
jojo@penguin:~/testpygame$ file ./test
./test: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
jojo@penguin:~/testpygame$ sudo ./test
./test: 1: ./test: ELF����: not found
./test: 1: ./test: ո��ME:: not found
./test: 2: ./test: Syntax error: word unexpected (expecting ")")
jojo@penguin:~/testpygame$ ls
test
test.c
''$'\001''@'$'\005''@@'$'\r\f''UH'$'\211\345''H'$'\215\005'']'$'\303''UH'$'\211\345''H'$'\203\354''0H'$'\307''E'$'\360''H'$'\213''E'$'\360''H'$'\211\307\350''H'$'\211''E'$'\350''H'$'\203''}'$'\350''u*H'$'\213''E'$'\360''H'$'\211\307\350''H'$'\211\306''H'$'\215''='$'\270\350\277\377\377\377\377\350''H'$'\215''U'$'\334''H'$'\213''E'$'\350''H'$'\211''Ѻ@H'$'\215''5H'$'\211\307\350''H'$'\211''E'$'\340\307''E'$'\374\353''# '$'\213''E'$'\374''H'$'\230''H'$'\215\024\305''H'$'\213''E'$'\340''H'$'\001\320''H'$'\213''H'$'\211\307\350\203''E'$'\374\001\213''E'$'\334''9E'$'\374'
the last hyeroglyphic caracters are a file name created by the program
not sure that was the result expected
# # mess-maker commented at 2020-05-20 15:52:11
last thing
crostini is a debian buster container running wayland and not Xorg
not sure it change something for you
jojo@penguin:~/testpygame$ echo $WAYLAND_DISPLAY
wayland-0
# # MyreMylar commented at 2020-05-20 15:53:59
hmm does SDL wayland support work yet?
# # MyreMylar commented at 2020-05-20 15:59:37
looks like it does but it still has lots of problems like no borders/title bars on windows yet in 2.0.12.
try adding:
os.environ['SDL_VIDEODRIVER'] = 'wayland'
at the very top of your pygame script?
# # MyreMylar commented at 2020-05-20 16:01:55
Probably also worth being aware of this list of SDL wayland bugs:
https://bugzilla.libsdl.org/buglist.cgi?quicksearch=wayland&list_id=42467