Using current git and mesa demos 8.0.1 for testing, with linux 2.6.39 with radeondrmfb on a radeon HD4850/RV770 graphics card, and HP LP2475w monitor via an HDMI cable. I'm using EGL_PLATFORM=drm running on the framebuffer console. What I see is that the demo programs run at the native resolution (1920×1200) but when the program ends (either by C-c/SIGTERM or by ending after the 5 seconds it runs for) it causes the display to power down, leaving the system in an unusable state. [I'm running X on vt7, so a switch to vt7 and back makes things work again, but if I wasn't running X, I'd need to reboot the system to reinitialise things.] I've tested with src/egl/opengles1/gears_screen, src/egl/opengles1/torus_screen and src/egl/openvg/lion_screen (the rest of the demos have glx dependencies or other deps which make them fail to run on the console). A log of a sample run is attached. Note the kernel HDMI hot plug events from the kernel log at the end which are presumably related. I'm not sure when these are issued due to the monitor being off. It might be at power down, or when I switch to vt7 and back again. Regards, Roger % EGL_LOG_LEVEL=debug EGL_PLATFORM=drm ./lion_screen libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module array libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so) libEGL info: use DRM for display (nil) libEGL warning: pci id for 3: 1002:9442, driver r600 libEGL debug: searching for pipe module r600 libEGL debug: loaded /usr/lib/x86_64-linux-gnu/egl/pipe_r600.so libEGL debug: the best driver is Gallium EGL_VERSION = 1.4 (Gallium) libEGL debug: searching for st module OpenVG libEGL debug: loaded /usr/lib/x86_64-linux-gnu/egl/st_OpenVG.so Found 16 modes: 0: 1920 x 1200 1: 1920 x 1080 2: 1600 x 1200 3: 1680 x 1050 4: 1600 x 1000 5: 1280 x 1024 6: 1280 x 1024 7: 1280 x 960 8: 1152 x 864 9: 1024 x 768 10: 1024 x 768 11: 832 x 624 12: 800 x 600 13: 800 x 600 14: 640 x 480 15: 640 x 480 Will use screen size: 1920 x 1200 1328 frames in 5.0 seconds = 265.441 FPS [28195.432084] HDMI hot plug event: Pin=3 Presence_Detect=0 ELD_Valid=0 [28195.434164] HDMI hot plug event: Pin=3 Presence_Detect=0 ELD_Valid=0
To follow up, it now appears that I can't reliably reproduce the issue with the src/egl/opengles1/gears_screen or src/egl/openvg/lion_screen demos (unless I kill them early with C-c/SIGTERM). src/egl/opengles1/torus_screen always turns off the screen. So this would appear to be an issue with the programs not cleaning up properly when terminated for the first two, or at all for the latter. However, I would still expect the display to remain powered on no matter the nature of how the program was terminated. Note that for the first two the display blanks for several seconds on termination, and I still get the HDMI hotplug events shown in the first message. This looks like it's doing something odd with the monitor anyway: I would not expect any resolution switching, messing with energy/power features of the monitor etc. when cleaning up. Since I'm using KMS, and am using the native panel resolution, I wouldn't expect to see any screen blanking at all. Regards, Roger
Created attachment 48167 [details] modeprint output
Created attachment 48168 [details] modetest output
The kernel KMS library responds to a case where the currently displayed surface is deleted by turning off the CRT. This is what I think you are seeing. I tweaked the GMA500 driver to stop this behaviour and personally I think that the default behaviour is wrong. You should also be able to get it back with alt-sysrq V
Alt-SysRq-V certainly restores the display to its former state (framebuffer console running at native resolution). Should I open a bug in the kernel bugzilla for this issue, or is this something that the mesa drivers can work around? I guess once you've killed a mesa-using program it's really in the hands of the kernel to do the necessary restoring of the state. Thanks, Roger
There could be multiple issues in this bug. First of all, I have never be able to tested those demos with a Radeon card. How EGL does modesetting may be wrong or trigger a bug somewhere else. Then there is no code to do VT switch. The screen will turn off when the demos end. For EGL on DRM, it is suggested to base your work on eglkms.c, not other EGL_MESA_screen_surface-based demos. You will have to do KMS manually: easier to see how it works and easier to debug on new hardware. You might also want to extend it to do VT switch. (Note that eglkms is currently broken with mesa git head)
Screen turning off should be fixed for src/egl/opengl/eglkms.c by http://cgit.freedesktop.org/mesa/demos/commit/?id=0e83890b5eae0236537d844c60375072210995d9 Note: you need mesa git master.
Is this still an issue?
Hi Michel, Just tried to verify this for you with current Debian unstable, but I can't get any EGL/DRM program to run. Here's an example: % EGL_LOG_LEVEL=debug EGL_PLATFORM=drm ./gears_screen libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module array libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so) libEGL info: use DRM for display (nil) libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no usable display) Not sure if I'm misconfiguring something here (since EGL_PLATFORM=drm used to pick up the r600 just fine). I did switch from a Radeon HD 4850 to 6800 in the interim, but thought it was supported just fine. drm and radeondrmfb are certainly set up. % EGL_LOG_LEVEL=debug EGL_PLATFORM=drm gdb ./gears_screen GNU gdb (GDB) 7.3-debian Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/rleigh/code/mesa-demos/src/egl/opengles1/gears_screen...done. (gdb) run Starting program: /home/rleigh/code/mesa-demos/src/egl/opengles1/gears_screen [Thread debugging using libthread_db enabled] libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module array libEGL debug: added egl_dri2 to module array libEGL debug: added egl_glx to module array libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so) Traceback (most recent call last): File "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16-gdb.py", line 59, in <module> from libstdcxx.v6.printers import register_libstdcxx_printers ImportError: No module named libstdcxx.v6.printers libEGL info: use DRM for display (nil) libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no usable display) Program received signal SIGSEGV, Segmentation fault. gbm_device_get_backend_name (gbm=0x0) at gbm.c:61 61 gbm.c: No such file or directory. in gbm.c (gdb) bt #0 gbm_device_get_backend_name (gbm=0x0) at gbm.c:61 #1 0x00007ffff7bc90c1 in dri2_initialize_drm (drv=0x41f360, disp=0x405010) at platform_drm.c:104 #2 0x00007ffff7bc34e0 in _eglMatchAndInitialize (dpy=0x405010) at egldriver.c:608 #3 0x00007ffff7bc3923 in _eglMatchDriver (dpy=0x405010, test_only=0) at egldriver.c:639 #4 0x00007ffff7bbe762 in eglInitialize (dpy=0x405010, major=0x404448, minor=0x40444c) at eglapi.c:323 #5 0x0000000000402991 in eglutInit (argc=<optimized out>, argv=<optimized out>) at eglut.c:194 #6 0x000000000040264e in main (argc=<optimized out>, argv=0x7fffffffeaa8) at gears.c:368 Regards, Roger
(In reply to comment #9) > Just tried to verify this for you Not for me. I asked because it seems to work for me with upstream Git. I just verified again it still does. > with current Debian unstable, but I can't get any EGL/DRM program to run. > Here's an example: > > % EGL_LOG_LEVEL=debug EGL_PLATFORM=drm ./gears_screen > libEGL debug: EGL search path is /usr/lib/x86_64-linux-gnu/egl > libEGL debug: added /usr/lib/x86_64-linux-gnu/egl/egl_gallium.so to module > array > libEGL debug: added egl_dri2 to module array > libEGL debug: added egl_glx to module array > libEGL debug: dlopen(/usr/lib/x86_64-linux-gnu/egl/egl_gallium.so) > libEGL info: use DRM for display (nil) > libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in eglInitialize(no > usable display) > > Not sure if I'm misconfiguring something here (since EGL_PLATFORM=drm used to > pick up the r600 just fine). I did switch from a Radeon HD 4850 to 6800 in the > interim, but thought it was supported just fine. Not sure what's up there. Maybe the PCI ID of your new card is missing somewhere on the Mesa 7.11 branch. Anyway, it doesn't seem directly related to this bug report.
Closing as per Michel's comment: > Not for me. I asked because it seems to work for me with upstream Git. I > just verified again it still does.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.