Created attachment 472683 [details] Output of glxinfo Description of problem: Impressive works fine when a the machine is used without external monitor (or projector, certainly). When an external screen is used, impressive does not start anymore, complaining that: FATAL: cannot create rendering surface in the desired resolution (1920x1080) The nouveau driver is used with mesa-dri-drivers-experimental. Version-Release number of selected component (if applicable): Version : 0.10.3 Release : 3.fc14 How reproducible: Every time an external monitor is used. (and not in "clone mode" obviously) Steps to Reproduce: 1. Go to the monitor preferences and activate an external monitor 2. Launch impressive with a PDF file, as usually 3. Impressive quits immediately Actual results: [tnorth@grouchy latex]$ impressive slides.pdf nv50_screen_get_param:162 - Unknown PIPE_CAP 11 nv50_screen_get_param:162 - Unknown PIPE_CAP 11 Welcome to Impressive version 0.10.3 Detected screen size: 1920x1080 pixels FATAL: cannot create rendering surface in the desired resolution (1920x1080) Expected results: If no external display is used, impressive works smoothly and runs with the following output: [tnorth@grouchy latex]$ impressive slides.pdf nv50_screen_get_param:162 - Unknown PIPE_CAP 11 nv50_screen_get_param:162 - Unknown PIPE_CAP 11 Welcome to Impressive version 0.10.3 Detected screen size: 1440x900 pixels nv50_screen_get_param:162 - Unknown PIPE_CAP 11 OpenGL renderer: Gallium 0.4 on NV86 Using GL_ARB_texture_non_power_of_two. Background rendering finished, used 37.1 MiB of disk space. Total presentation time: 0:42. Additional info: It seems that setting the flag -f (no fullscreen) with a custom geometry (1920x1080) works. But unfortunately the windows borders are present.
First of all, this works for me with the same drivers you are using (and the same external resolution), so I need some more info: What is the exact set of options (-f -g axb ?) that does work for you? When your external display is connected, is it the only active display, or are you using a dual setup (such as laptop LCD + external) with xinerama or similar? In that case, the effective screen size is larger than 1920x1080 and might be simly too large to prerender on. Does the "-e" option help?
> What is the exact set of options (-f -g axb ?) that does work for you? impressive -f -g1920x1080 file.pdf <= this works well impressive -g1920x1080 file.pdf <= this fails It is a dual setup. The display is extended (1440x900 + 1920x1080). So maybe the effective screen is too large, but impressive reports it to be 1920x1080 in its error message: "Detected screen size: 1920x1080 pixels" Using the "-e" option does not seem to change anything. Thanks, Thibault
Further analysis shows that this works fine if you disable the internal display and use the external one only. Otherwise, with both active, it fails for the following reason: impressive determines the resolution as 1920x1080 (using xrandr) pygame.display.list_modes() lists 1440x900 as the highest resolution (laptop screen) impressive tries to get a rendering surface with pygame.display.set_mode(), requesting 1920x1080 with flags OPENGL|DOUBLEBUF|FULLSCREEN. This results in "No video mode large enough for 1920x1080", leading to the response you actually see. I don't think that impressive could work around pygame's shortcomings here (maybe use borderless window mode?), but I'll point the impressive developer and pygame folks to this bug report (before resolving with UPSTREAM).
Martin J. Fiedler, the Impressive developer, writes: "The problems arise from the complete complete lack of multi-screen support in SDL and hence PyGame. There seems to be an environment variable (undocumented, of course :/) called SDL_VIDEO_X11_XINERAMA_SCREEN that might be worth being experimented with, though." Thanks, Martin! Thibault, please try with SDL_VIDEO_X11_XINERAMA_SCREEN set to 1 (0 would be the first screen). I'll do so asap.
Thanks Michael. I will try asap, when I have access to that screen again.
OK, I've tried with several values for SDL_VIDEO_X11_XINERAMA_SCREEN. It seems that sometimes (?) it convinces SDL to use the resolutions of the second monitor, so that impressive starts in Full HD resolution. But the fullscreen canvas is not displayed on the external monitor - it seems it is located at (0,0) on the extended virtual screen, which (for LCD left, external right) means most of it is on the LCD (with the bottom cut off) and a small strip is displayed on the external monitor. What's worse: even after exiting impressive the parts to the right of that strip remain dead (as in: frozen content, not updated). Maybe this can be worked around by positioning the external monitor (i.e. the screen in the virtual desktop) to the left of the LCD at (0,0), but I haven't experimented further, because my experiences with krandrtray were not completely deterministic. For presentations, the external resolution would be smaller. Setting both devices to the same resolution and to "clone" should work. In any case, this is not an impressive bug. Should we close this UPSTREAM, since it's not fedora-specific and pygames problem stemming from SDL? Or WONTFIX?
Closing CANTFIX since we cannot fix this, upstream cannot either, and upstream's dependency SDL does not support multi-monitor setups explicitly either. For the record: In a multi-monitor setup, try enabling one monitor only or setting both to the same resolution (and cloning mode). Feel free to experiment with SDL_VIDEO_X11_XINERAMA_SCREEN and report success here and upstream (impressive).