Created attachment 18499 [details] Xorg log output. I have a Sony Vaio SR11M with a Intel Cantiga Integrated Graphics (aka G45) chipset, and I am using Xorg 7.3 with xserver-xorg-video-intel 2.4.0. When starting the Xorg (using the 'Xorg' command), the display goes blank. The Xorg server is running, however the built-in LCD of the laptop won't show anything, it remains blank. I discovered that the xserver initializes two pipes: Pipe A and Pipe B. The log says that the pipe A is ON an connected to the VGA output, whereas the pipe B is ON and connected to the LVDS (presumably the built-in LCD display of the laptop). When the Xorg is loaded, it starts to spit out the same error over and over again: (EE) intel(0): underrun on pipe B! When switching to a normal tty, it will stop spitting out that error. And, obviously, when going back to X, it will start throwing up the underrun error again. I know there have been some similar issues around in i386 architectures but in pipe A, typically with single-pipe old cards. I believe this is a problem of quirks, where the driver doesn't initialize properly the pipes and hence the built-in LCD panel is not enabled for displaying the X-window system. My system is a Debian GNU/Linux running on a 2.6.27-rc4 kernel. The intel driver is at 2.4.0 version, whereas the Xorg server is at version 1.4.99.906. Please find enclosed my Xorg.0.log. Best regards,
Created attachment 18500 [details] Here is my xorg.conf (just in case)
Created attachment 18501 [details] Linux 2.6.27-rc4 dmesg output.
I guess it might have been fixed in the latest 2.4.2 release. Worth trying.
(In reply to comment #3) > I guess it might have been fixed in the latest 2.4.2 release. Worth trying. > System: linux 2.6.26-1-686 (x86) Chipset: "852GM/855GM" xserver-xorg 1.4.99.906 I compiled the latest git (sept. 01) and get the following errors in xorg.log: (EE) intel(0): underrun on pipe A! (EE) intel(0): underrun on pipe B!
Created attachment 18607 [details] xorg.0.log
Hi Gordon Jin, Thank you for taking your time with my report. I'm at the job right now, but as soon as I get home, I will try to compile the xserver-xorg-video-intel-2.4.2 on my Debian and let you know if it works or not.
(In reply to comment #4) > I compiled the latest git (sept. 01) and get the following errors in xorg.log: > (EE) intel(0): underrun on pipe A! > (EE) intel(0): underrun on pipe B! Jos, are you seeing blank screen issue too? Just having the error messages doesn't hurt.
bugzilla-daemon@freedesktop.org wrote: > Jos, are you seeing blank screen issue too? Just having the error messages doesn't hurt. No black screen, no other problem, only the error messages (which don't always appear). So I should not worry about this driver! Cheers & thanks, Jos v.W. ----- Debian GNU/Linux: the Universal Operating System
> --- Comment #3 from Gordon Jin <gordon.jin@intel.com> 2008-08-31 18:03:26 PST --- > I guess it might have been fixed in the latest 2.4.2 release. Worth trying. > The error message and LVDS flickering were reintroduced for me by 48d4b0ae50affd7fa442271046eefba74de7ff2c, so 2.4.0 and 2.4.2 have the bug, and 2.4.1 doesn't. Cheers, Julien
(In reply to comment #9) > so 2.4.0 and 2.4.2 have the bug, and 2.4.1 doesn't. I am sorry but 2.4.1 too (sometimes) shows the error message, moreover it produces horizontal stripes on the background of my desktop! Cheers, Jos v.W.
Hi again, I didn't have time to try out the 2.4.2 on my Debian-amd64 yet, but I know the bug has been around for me since 2.3.2. However, I have noticed that *sometimes* there is no message about the underrun, but I still get a blank screen. Also, I have noticed that, when switching from console to graphics mode, the display lights up a little bit (from black to dark navy blue) and there are several dark bars which appear horizontally (something like denoting the display is initializing) but one can hardly see them. These bars disappear in less than a two seconds and the dark navy blue screen (blank screen but lightened up) remains. In this case, no underrun messages are seen in the log file. This is quite strange, and I don't know anymore if it belongs to the intel driver or to the kernel, but it looks to me that is a problem with new laptops (using LVDS) and concretely with the Intel X4500. I don't have time to compile the bunch of git sources for the 2.4.2, is there anyway I can do it easily? Otherwise, I will have to wait for the Debian people to include it in experimental (probably a few days still).
On Tue, Sep 2, 2008 at 01:36:10 -0700, bugzilla-daemon@freedesktop.org wrote: > I don't have time to compile the bunch of git sources for the 2.4.2, is there > anyway I can do it easily? Otherwise, I will have to wait for the Debian people > to include it in experimental (probably a few days still). > version 2:2.4.1-1 in experimental is actually 2.4.2, only difference is the version bump. sorry about that.
I tried, just now, the xserver-xorg-video-intel 2.4.2 along with xserver-xorg-core 1.4.906 and still I have the same problem. There is nothing on the LCD display of my laptop. However, the "underrun" message has gone away. It seems that the LCD (LVDS) cannot be initalized or backlit, I don't know anymore what could cause this.
(In reply to comment #13) > > However, the "underrun" message has gone away. I keep getting lots of errors with 2.4.2 (compiled for 1.4.99.906): not only 'underrun' but also (EE) intel(0): tried to update DSPARB with both planes enabled! ---- (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): underrun on pipe B! (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): underrun on pipe B! (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "CRTDDC_A:ddc2" registered at address 0xA0. (II) intel(0): I2C device "CRTDDC_A:ddc2" removed. (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): tried to update DSPARB with both planes enabled! (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! (EE) intel(0): underrun on pipe B! ----- The Xorg.log becoming longer and longer!
Hi, I just tried the Xorg 7.4 (xserver-1.5.0) with the xserver-xorg-video-intel-2.4.2 in Debian Sid and still I have same problem: my screen is ligthened up but the screen is totally blank. No message errors, the log says that VGA is connected to pipe A (which is off) and LVDS is connected to pipe B (which is on). My frustration grows, I hope there is not a big problem with the new Intel X4500. Good night!
Hi, I have visited #xorg-devel (at irc.freenode.net) and, after a lot of testing on my Vaio SR11M, I have noticed that Xorg is running properly even with the blank screen. Even I can run glxgears and other applications with no problems. Therefore, the last possibility to fix this is concerning a probable quirk that is needed, since the output of Xorg goes to a wrong place, whereas it should go to the LVDS TFT of the laptop. Please find enclosed an lspci -vvmm.
Created attachment 18752 [details] lspci -vvmm Hopefully you can add a quirk looking at the lspci -vvmm.
UPDATE: I connected a VGA monitor and the DRI is working. So this confirms that the problem is in defaulting the output to the laptop's monitor (LVDS), where I only see a blank screen. By the way, glxgears shows poor performance and gives this error: Failed to initialize TTM buffer manager. Falling back to classic. Here is the glxinfo output (that I can only see from the VGA monitor): name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.2 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset 20061102 OpenGL version string: 1.4 Mesa 7.1 rc3 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shading_language_120, GL_ARB_shadow, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_cull_vertex, GL_EXT_compiled_vertex_array, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_vertex_array, GL_3DFX_texture_compression_FXT1, GL_APPLE_client_storage, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_separate_stencil, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_point_sprite, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_NV_vertex_program, GL_NV_vertex_program1_1, GL_OES_read_format, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SUN_multi_draw_arrays visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x22 16 dc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x71 32 tc 0 16 0 r . . 5 6 5 0 0 0 0 0 0 0 0 0 0 None Good luck!
Created attachment 18786 [details] get-edid error output
I think the problem is with a bugged edid/vbe. I've attached the output of the command 'get-edid'; The command fail with: The EDID data should not be trusted as the VBE call failed Error: output block unchanged I've seen the same thing using the tool vbetest (lrmi packet), cause of a different vbetest output using vesa or intelfb for the framebuffer; anyhow using the framebuffer i can get 1280x800 using vesa vga=866, and using X i can get 1280x800 using vesa with the modeline: Modeline "1280x800_76.00" 108.77 1280 1360 1496 1712 800 801 804 836 -HSync +Vsync The intel X driver probes also this modeline with no success: (II) intel(0): Not using mode "1280x800_76.00" (vrefresh out of range) (EE) intel(0): Output LVDS enabled but has no modes (EE) intel(0): No valid modes. (II) UnloadModule: "intel" I think the solution is using something like the IGNOREEDID options, but it don't work, so i think it does not exist for intel driver (as I read from the man page)
I've got this problem too. My notebook is ths vaio SR11m
i've searched a lot and i've found some useful information; i've found a ubuntu user having no problem with ubuntu and x4500 [sony bz] and i'm trying to contact him; and i've found that the problem is solved [i think in ubunut: https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel read about LVDS in the page!
I changed the topic of the bug, since it is now clear that the problem is a missing quirk for this kind of laptop: Sony Vaio SR11M. On Ubuntu, some users reported that they get a blank screen using the xserver-xorg-video-intel driver (new laptops with LVDS displays and X4500). The Ubuntu developers added a few quirks for certain laptops to fix their users problems. I am using Debian GNU/Linux, but I tried Ubuntu with the latest quirks and still I get a blank screen using the intel driver. Therefore, I assume that my blank screen is just an issue with the LVDS, thus needing a quirk for this laptop. Please, contact me or send me any email with testing instructions, since developers may not have (and probably won't) this specific model from Sony Vaio. Looking forward to hearing from you.
I'm not too expert in linux but I've installed Debian in my Desktop PC from 1 year so if someone want to send me some instructions I'll be happy to help fixing this bug. To be exact i got a black (not blank) screen when the graphic server start, but i think it's the same problem. I've just tried to install Fedora, Ubuntu, Kubuntu and BackTrack3 but when the graphical installe begin i got a black screen. Waiting for instructions (and hoping s'one find a solution :))
I suspect this bug and #16638 are related, which sounds like it isn't a quirk needed at all. But i'm not sure.
I believe this is not related to #16638, since the problem on my laptop has nothing to do with pipes. In the beginning, I had some missconfiguration problems with pipes, but now Pipe A and Pipe B are well configured and there are no underrun messages at all. Furthermore, on #16638, there is an external display connected to Pipe A. I have tested an external display connected to my VGA output and it works (Pipe A). Pipe B is also enabled and my laptop's display is connected to the Pipe B, however nothing is seen on the laptop's display (whereas the Xorg is shown on Pipe A, my VGA external monitor, and 3D works although it is crappy, glxgears shows only 700FPS). So here the main problem is that Pipe B is enabled and the LVDS display is connected to Pipe B, but nothing is on the display when Xorg is started.
Hello, I have the same problem on the sony vgnSZ71-E/B with the 2.4.97 drivers but the 2.4.2 drivers are working fine. So I think that it is a problem with sony laptops in general but I mind be wrong. regards M. T.
Hello there, I am currently using an up to date ubuntu intrepid alpha 5. meaning 2.4.1 driver package. I did try x86 and amd64 install, and I did try the git drivers with some simple git-clone commands. So far, i am getting the exact same problem as Claudio. The intel driver works just fine, but only on the VGA connector. If i don't connect the VGA cord, i can hear the gdm sounds. My guess is the intel driver starts without any problem. I still get the black screen on laptop's display. If anyone has something to test, any idea that could be working, i'll try it. Aurélien
Jos, I'm pretty sure you have a totally separate issue. Please file another bug report for it after testing with a more recent driver (2.2.0 is missing several fixes for LVDS detection). Claudio's bug really does seem like a pipe programming issue; after 2.4.0 I think we fixed some Cantiga related problems there (we're not supposed to program DSPARB or FW_BLC on those chips iirc), but apparently newer drivers are busted too? Hmm... I'll go look at some of the referenced URLs.
Jesse, i've the same hardware of Claudio,; can you expose some test to use we can do helping you to fix the issue ? thanks for the attention Giovanni Pellerano
Well, you could try commenting out the call to i830_update_dsparb to see if that makes the problem go away... If so at least we'll have narrowed it down.
can you explain it; where i've to comment it? On Tue, Sep 23, 2008 at 2:58 AM, <bugzilla-daemon@freedesktop.org> wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=17292 > > > > > > --- Comment #31 from Jesse Barnes <jbarnes@virtuousgeek.org> 2008-09-22 > 17:58:39 PST --- > Well, you could try commenting out the call to i830_update_dsparb to see if > that makes the problem go away... If so at least we'll have narrowed it > down. > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >
can you explain it; where i've to comment it?
jesse, i have made the test you've asked for, still the same problem, plus i can't ctrl+alt+FXX to any other terminal it makes the xorg server crash. src/i830_display.c (1473à /* if (!DSPARB_HWCONTROL(pI830)) i830_update_dsparb(pScrn); */ is that what you've asked for ?
Yeah that's the line, thanks for testing. On G45 DSPARB_HWCONTROL should be true, and looks like it probably is in your case, which means we have a bug elsewhere. So 2.4.0 and 2.4.97 are broken but 2.4.2 works for everyone? Maybe one of you could use 'git bisect' to figure out where things got fixed between 2.4.0 and 2.4.2? That should give me a clue about what needs fixing in 2.4.97...
Hi Jesse, As I said in my comment #13, I have already tried 2.4.2 and I got the same result. In fact, xserver-xorg-video-intel-2.4.2 is now on Debian and I have it installed, but the blank screen won't disappear. Is there anywhere else where this bug could have been introduced? By the way, who said it is working with 2.4.2? For me it hasn't worked never, since 2.3.2 until 2.4.2.
I was looking at comment #27; that must be a separate issue then. It would be harder to bisect between 2.3.2 and 2.4.2, but it's worth a try... The 'git help bisect' man page is pretty good, care to give it a shot?
Ok, I see that nobody says nothing here and we all have a serious problem with the intel driver. Therefore: Jesse, I am an average user and didn't get the bisect thing. Even more, I haven't got any driver working with my X4500 from 2.3.2 to 2.4.2, but still, I will ask you a couple of questions and then I'll try to find some time to help you with the bisect, since I need 3D at my studies and in daily life, and I guess many people would like it too (vesa is kind of thick on our laptops). My questions are: I am using Debian Sid with Xorg 7.4 and vesa driver. For the intel driver, can I just checkout with git and 'make install' from the directory? I mean, should I checkout the revision 2.3.2 and the revision 2.4.2, then try both separately and then bisect? Because I don't know if checking out the video-intel driver, will require also to checkout the whole Xorg, since there are dependencies with libdrm (I presume) and maybe other libraries. Could you please instruct me a little bit more so that we can finally close this ticket? P.S.- Giovanni pointed out an interesting fact also in comment #20, where the EDID are not definitely correct and there might be a problem with the modes when starting the xserver. And that could also lead the LVDS to be blank, since the xserver doesn't accept any mode with the intel driver.
(In reply to comment #38) > Ok, I see that nobody says nothing here and we all have a serious problem with > the intel driver. Therefore: > > Jesse, I am an average user and didn't get the bisect thing. Even more, I > haven't got any driver working with my X4500 from 2.3.2 to 2.4.2, but still, I > will ask you a couple of questions and then I'll try to find some time to help > you with the bisect, since I need 3D at my studies and in daily life, and I > guess many people would like it too (vesa is kind of thick on our laptops). My > questions are: > > I am using Debian Sid with Xorg 7.4 and vesa driver. For the intel driver, can > I just checkout with git and 'make install' from the directory? I mean, should > I checkout the revision 2.3.2 and the revision 2.4.2, then try both separately > and then bisect? Right. If you want to try an even newer version (like the master branch from git) you'll also need to build libdrm from git. See http://wiki.x.org/wiki/Development/git for some instructions on grabbing & building the drm tree. > Because I don't know if checking out the video-intel driver, will require also > to checkout the whole Xorg, since there are dependencies with libdrm (I > presume) and maybe other libraries. Could you please instruct me a little bit > more so that we can finally close this ticket? It should just depend on libdrm; building against a 1.5 X server *should* work fine. > P.S.- Giovanni pointed out an interesting fact also in comment #20, where the > EDID are not definitely correct and there might be a problem with the modes > when starting the xserver. And that could also lead the LVDS to be blank, since > the xserver doesn't accept any mode with the intel driver. Yeah, it may be that we have to get the panel info for this machine from the VBIOS. I recently pushed some fixes for other machines that might help here too. Let me know if you have trouble building the driver; testing the latest git bits would be a good first step.
Hi Jesse, Trying to build the xf86-video-intel from git gives an error: checking for DRM... configure: error: Package requirements (libdrm >= 2.3.0) were not met: No package 'libdrm' found I already git cloned the libdrm and did make and make install. I also set the PKG_CONFIG_PATH to /opt/xtest (where I installed the libdrm from git), but it won't help. Any clue? (I'm quite dummy in this matter)
PKG_CONFIG_PATH should be set to /opt/xorg-test/lib/pkgconfig for example (you have to point at the actual pkgconfig dir not just the top level prefix). Hope that helps.
Thank you very much, now it builds. However, there is some error about UXA and the compilation doesn't go till the end: ../doltcompile gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/xorg -I/usr/include/pixman-1 -I/opt/xtest/include -I/opt/xtest/include/drm -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -I/usr/include/xorg -I/usr/include/pixman-1 -g -O2 -MT uxa-glyphs.lo -MD -MP -MF .deps/uxa-glyphs.Tpo -c -o uxa-glyphs.lo uxa-glyphs.c uxa-glyphs.c: In function ‘uxa_glyphs_init’: uxa-glyphs.c:85: warning: implicit declaration of function ‘dixLookupPrivate’ uxa-glyphs.c:85: warning: nested extern declaration of ‘dixLookupPrivate’ uxa-glyphs.c:85: warning: cast to pointer from integer of different size uxa-glyphs.c: In function ‘uxa_unrealize_glyph_caches’: uxa-glyphs.c:116: warning: cast to pointer from integer of different size uxa-glyphs.c: In function ‘uxa_realize_glyph_caches’: uxa-glyphs.c:156: warning: cast to pointer from integer of different size uxa-glyphs.c:189: error: too many arguments to function ‘pScreen->CreatePixmap’ uxa-glyphs.c: In function ‘uxa_glyphs_fini’: uxa-glyphs.c:237: warning: cast to pointer from integer of different size uxa-glyphs.c: In function ‘uxa_glyph_cache_hash_lookup’: uxa-glyphs.c:253: error: ‘struct _Glyph’ has no member named ‘sha1’ uxa-glyphs.c:260: error: ‘struct _Glyph’ has no member named ‘sha1’ uxa-glyphs.c:260: error: ‘struct _Glyph’ has no member named ‘sha1’ uxa-glyphs.c: In function ‘uxa_glyph_cache_hash_insert’: uxa-glyphs.c:277: error: ‘struct _Glyph’ has no member named ‘sha1’ uxa-glyphs.c:277: error: ‘struct _Glyph’ has no member named ‘sha1’ uxa-glyphs.c:279: error: ‘struct _Glyph’ has no member named ‘sha1’ uxa-glyphs.c: In function ‘uxa_glyph_cache_upload_glyph’: uxa-glyphs.c:359: warning: cast to pointer from integer of different size uxa-glyphs.c:360: warning: implicit declaration of function ‘GlyphPicture’ uxa-glyphs.c:360: warning: nested extern declaration of ‘GlyphPicture’ uxa-glyphs.c:360: error: subscripted value is neither array nor pointer uxa-glyphs.c: In function ‘uxa_glyph_cache_buffer_glyph’: uxa-glyphs.c:465: error: subscripted value is neither array nor pointer uxa-glyphs.c: In function ‘uxa_buffer_glyph’: uxa-glyphs.c:504: warning: cast to pointer from integer of different size uxa-glyphs.c:505: error: subscripted value is neither array nor pointer uxa-glyphs.c:539: error: subscripted value is neither array nor pointer uxa-glyphs.c: In function ‘uxa_glyphs’: uxa-glyphs.c:803: error: ‘CREATE_PIXMAP_USAGE_SCRATCH’ undeclared (first use in this function) uxa-glyphs.c:803: error: (Each undeclared identifier is reported only once uxa-glyphs.c:803: error: for each function it appears in.) uxa-glyphs.c:803: error: too many arguments to function ‘pScreen->CreatePixmap’ uxa-glyphs.c:842: error: subscripted value is neither array nor pointer make[2]: *** [uxa-glyphs.lo] Error 1 make[2]: Leaving directory `/root/xf86-video-intel/uxa' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/xf86-video-intel' make: *** [all] Error 2 I hope it can be avoided or fixed somehow to continue with the process. We have to discover what's going so that at last we can use the X4500 properly :-) I'll wait for you answer and continue working on the compilation. Thanks again.
Hi Jesse, I updated the xf86-video-intel with the latest git revision (7th October, at 10:00 o'clock). Now UXA compiles, but there is a problem in linking, and I think is that I'm doing something wrong. After the whole compilation of the sources, there is a linking error like this: /usr/bin/ld: cannot find -ldrm_intel collect2: ld returned 1 exit status make[4]: *** [intel_drv.la] Error 1 make[4]: Leaving directory `/root/xf86-video-intel/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/root/xf86-video-intel/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/xf86-video-intel/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/xf86-video-intel' make: *** [all] Error 2 I exported the variable PKG_CONFIG_PATH and I used ./autogen.sh --prefix=/opt/xtest, where I have my copy of the libdrm built from git. Can you please help me with this? Once it is linked, I could test the fresh xf86-video-intel and hopefully we'll finally fix it.
How recent is your DRM build? You should have a /opt/xtest/lib/libdrm_intel.so in there somewhere. If you do but it's still not linking your configure must not be picking up the right paths...
I am having exactly the same issue with X4500MHD on a new Sony VGN-SR19XN. I am watching intently to see if Claudio and Jesse can fix the bug.
Yes, I have the libdrm_intel.so in /opt/xtest/lib, but the configure doesn't pick it up when building the Intel driver. Any clue?
> --- Comment #46 from Claudio Camacho <claudiomkd@gmail.com> 2008-10-07 21:26:10 PST --- > Yes, I have the libdrm_intel.so in /opt/xtest/lib, but the configure doesn't > pick it up when building the Intel driver. > > Any clue? > presumably 'pkg-config --libs libdrm' includes -L/opt/xtest/lib? @DRM_LIBS@ should be used whenever -ldrm_intel is, so this looks like a bug in src/Makefile.am.
well i can compile drivers without any problem, but i don't understand how git-bisect work. If you have any instruction, i could be quite helpful i guess.
Hi Jesse, Now I compiled it. I had to manually edit the Makefile, but now they link. Now, the matter is different. I only checked out the libdrm and xf86-video-intel from git, but no other modules. So, when I do like this: ~# export $LD_LIBRARY_PATH=/opt/xtest/lib ~# Xorg The Xorg loads the old libdrm under /usr/lib and the old intel driver under /usr and not under /opt. Do I have to download the whole xorg source and compile all modules to test the xf86-video-intel? Or there is another way to test only the driver and the libdrm without building everything from scratch?
Alright, to sum up: I downloaded the whole Xorg source. I compiled and placed it at /opt/gfx-test. Then I exported $LD_LIBRARY_PATH=/opt/gfx-test/lib and run with this: ~$ startx -- /opt/gfx-test/bin/Xorg -verbose The result is still the same :-( I get a blank screen. However, maybe it is worthy to mention that now the screen pops up the gray background of the empty Xorg for some tenths of second and then it gets blank as usual. Please find enclosed my fresh Xorg.0.log for more details.
Created attachment 19542 [details] Xorg.0.log (xorg 1.5.99 + xf86-video-intel 2.5) Xorg log generated from the whole Xorg sources from git as of 2008/10/10 22:00.
Hi Claudio, if you're able to get on #xorg-devel we could try and work through this bug. Nick is "justyn". I certainly concur with your thoughts that it is an EDID error. You can see that the EDID call is failing. One (of the many) things I don't understand is why X doesn't spit out a proper error when it fails to get the necessary info about the LVDS over EDID. It just carries on regardless.
Thinking some more, I don't think the EDID error can be the cause, I think it must be a symptom instead. If Xorg doesn't get EDID data it will use whatever parameters are already set up or try and grab some from the BIOS. But EDID only really specifies things like resolution and refresh rate, so how could the absence of any of these parameters cause the LVDS to display nothing at all?
I am a GNU/Linux user but I am quite a rookie. However, I will try to be on xorg-devel (maybe this evening or during the weekend) and we can discuss about the bug.
Created attachment 19581 [details] Xorg.0.log with --enable-debug and ModeDebug Don't misunderstand, I'm not very experienced with Xorg hacking either! Anyway, I compiled Xorg 1.5.1 (not the Intel driver) with --enable-debug because there are some debug statements in the DDC, EDID etc code that I hoped might be interesting. I've run it on the SR19XN I have here (I think it is the same model as your laptop but an international variant). It doesn't seem to tell us anything new - just that it is not getting EDID data for the panel. I'll attach the Xorg log. It shows both debug output from Xorg through --enable-debug and debug output from the Intel driver from setting ModeDebug in the device section of xorg.conf. Here is the output from around where the problem seems to be occurring: (II) intel(0): Output VGA using monitor section Configured Monitor (II) intel(0): I2C bus "CRTDDC_A" initialized. (II) intel(0): Output LVDS has no monitor section (II) intel(0): I2C bus "LVDSDDC_C" initialized. (II) intel(0): Attempting to determine panel fixed mode. (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. Error reading EDID block Error reading EDID block Error reading EDID block Error reading EDID block (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. No EDID block returned (II) intel(0): found backlight control method /sys/class/backlight/acpi_video0 Mapping VGAMem base: a0000, realBase: a0000, alignOff: 0 base: b77bc000 aligned base: b77bc000 Unmapping VGAMem alignment offset: 0 (II) intel(0): EDID for output VGA (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. Error reading EDID block Error reading EDID block Error reading EDID block Error reading EDID block (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. No EDID block returned (II) intel(0): EDID for output LVDS (II) intel(0): Not using default mode "1152x864" (exceeds panel dimensions) (II) intel(0): Not using default mode "1280x960" (exceeds panel dimensions) (II) intel(0): Not using default mode "1280x960" (exceeds panel dimensions) ........and so on.
I'm feeling pretty stuck at this point. Could a dev weigh in with what we should be looking at/doing next? Also, if the only problem is that Xorg isn't getting EDID from the laptop screen, surely it *must* be possible to get it displaying something by specifying the parameters manually. Is that a correct assumption? Because I've been trying but with no luck. The vesa driver does work and display ok on the panel. It defaults to the wrong resolution (1024x768) but you can force it to 1280x800 and it's fine with that.
(In reply to comment #56) > I'm feeling pretty stuck at this point. > > Could a dev weigh in with what we should be looking at/doing next? > > Also, if the only problem is that Xorg isn't getting EDID from the laptop > screen, surely it *must* be possible to get it displaying something by > specifying the parameters manually. > > Is that a correct assumption? Because I've been trying but with no luck. > > The vesa driver does work and display ok on the panel. It defaults to the wrong > resolution (1024x768) but you can force it to 1280x800 and it's fine with that. > It looks like the EDID failure is normal though; several laptops don't have EDID info available since they expose panel timing in the VBIOS instead. Since you're getting a valid mode list back, I don't think a lack of mode information is the problem here. It seems like we're doing something else wrong when programming the panel, though I'm not sure what. Did I already ask one of you for a copy of your video ROM (I don't seem to have a copy on this machine at least)? It should be available in your sysfs directory: # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom then attach your rom.bin to this bug.
> It looks like the EDID failure is normal though; several laptops don't have > EDID info available since they expose panel timing in the VBIOS instead. Yes i think it's the vbebios buggy :( Since you're getting a valid mode list back, we don't get valid mode list back; it says that all modes are out of vert refresh range; no one of us know modes that works with the intel driver becouse no one has success with it; all the sr work with vesa Modeline "1280x800_76.00" 108.77 1280 1360 1496 1712 800 801 804 836 -HSync +Vsync but the intel driver says that i'ts out of range too. I don't think a lack of mode information > is the problem here. It seems like we're doing something else wrong when > programming the panel, though I'm not sure what. Did I already ask one of you > for a copy of your video ROM (I don't seem to have a copy on this machine at > least)? It should be available in your sysfs directory: > # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ > # echo 1 > rom > # cat rom > /tmp/rom.bin > # echo 0 > rom > then attach your rom.bin to this bug. > i'm going to attach it;
Created attachment 19583 [details] VBEBIOS ROM.BIN [VAIO SR19XN, VAIO SR11M)
Created attachment 19584 [details] Video ROM of SR19XN Bsdiff shows that there are some differences between my video ROM from an SR19XN and Giovanni's (from SR11M?). For completeness I attach mine too.
Giovanni, it doesn't say *all* modes are out of range, at least on mine. If you look at my attachment two comments back, "Xorg.0.log with --enable-debug and ModeDebug", you can see that after rejecting 40 modes it prints out 18 probed modes without errors. The top one of these is the correct panel resolution, 1280x800. That's assuming I'm not vastly misunderstanding something.
Okay, I'm at the university right now, so I can't say much right now. But I do have the same problem with my Sony Vaio SR19XN. The external screen works like a charm, and the internal display stays dark. Well, not exactly dark. The panel-backlight is active, but the screen is black. I can hear the Gnome-sounds, so the X-Server starts up normal. There are some warnings listed in the Xorg.log: (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x55018a00 to 0xfc00e700 (WW) intel(0): ESR is 0x00000011, page table error (WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE (WW) intel(0): Existing errors found in hardware state. As far as I remember, there are no error-messages - "only" these warnings.
Could you test with git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next branch and xf86-video-intel master branch? There're new GM45/G4X fixes and hope that could fix this problem as well.
I can't manage to compile the drm-intel-next branch. When I run, ie "make drivers/gpu" or "make include/drm" it just comes back with: make: Nothing to be done for include/drm. Any pointers? How do I compile just the required modules without building the whole kernel et al from scratch, or is that not possible?
With the kernel 2.6.27 git7 something thifferent happens. Ive attached the full log; i got a system freeze; in the log i can read: (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): [DRI] installation complete (II) intel(0): xf86BindGARTMemory: bind key 0 at 0x07f7f000 (pgoffset 32639) (WW) intel(0): xf86BindGARTMemory: binding of gart memory with key 0 at offset 0x7f7f000 failed (Invalid argument) Fatal server error: Couldn't bind memory for HW status
Created attachment 19728 [details] xorg log | kernel 2.6.27 git 7
Hi, I tried 2.6.27-git8, because there are fixes in the i915 and especially for the GM45 series, and I get the same problem as Giovanni with -git7. The screen does not get however blank this time. The Xorg tries to start, the screen goes blank for a second, then it comes back with the console cursor, and it stays there. At that point the Xorg is hanged, and only a blank console with the cursor (not blinking) on the top left corner is shown. I can press power button and shut down the computer, but Xorg still won't work. Please find enclosed my Xorg.0.log for 2.6.27-git8 using xserver 1.5 and xf86-video-intel-2.4.2.
Created attachment 19733 [details] Xorg.0.log-2.6.27-git8 Xorg.0.log from Xorg -verbose using 2.6.27-git8, xserver 1.5 and intel-2.4.2.
i get the same; :( so there is the need to contact some kernel developer i think;
Hi Giovanni, I don't think that it is totally about the kernel. Just notice that the LVDS does something strange that is difficult to see because it is really dark, and then it gets blank. Moreover, the vesa driver works, so I think it is a thing with the xf86-video-intel driver. I also tested the xorg from git with the -git8, and the same result: blank screen :(
*** Bug 18107 has been marked as a duplicate of this bug. ***
Created attachment 19747 [details] output of monitor-probe -v vesa on Sony VAIO VGN-FW140E/H laptop I am adding the output of monitor-probe -v vesa because it seems to point to a firmware BIOS problem, specifically a wrong checksum: probing EDID probing EDID using VBE (port 0) vbe: BIOS chksum wrong vbe: int 10h points to c000:0014: e9 65 21 db 40 00 e0 0a VBE version: 3.0, oem version = 1.0 Memory: 131008k OEM name: Intel(r)Cantiga Graphics Chip Accelerated VGA BIOS Vendor name: Intel Corporation Product name: Intel(r)Cantiga Graphics Controller Product revision: Hardware Version 0.0 EDID: Error (0x4f15): 0x014f Retrying with old LRMI interface VBE version: 3.0, oem version = 1.0 Memory: 131008k OEM name: Vendor name: Product name: Product revision: EDID: Error (0x4f15): 0x014f vbe: BIOS chksum wrong vbe: int 10h points to c000:0014: e9 65 21 db 40 00 e0 0a VBE version: 3.0, oem version = 1.0 Memory: 131008k and it repeats several more times with similar results. I don't know if this is of any help but it could suggest a problem with all Sony laptops using the GM45 driver.
Created attachment 19748 [details] Xorg.0.log from Mandriva 2009 pwp running on Sony VAIO VGN-FW140E/H
Ok, so the panel info in your vbios looks good: * panel type 00: 1280x800 clock 68200000 info: LVDS: 0x42000300 PP_ON_DELAYS: 0x01000900 PP_OFF_DELAYS: 0x00800900 PP_DIVISOR: 0x00270f06 PFIT: 0x20000000 timings: 1280 128 50 356 800 8 2 2 But I wonder if we have the right PP_* values. Can one of you attach the output of the 'intel_reg_dumper' program? Also, it looks like the most recent logs contain other bugs, related to memory management, can you update your git trees and try again? It's probably worth running the latest kernel bits as well, pull down Eric's DRM tree at git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel and check out the drm-intel-next branch. That has all the latest fixes.
Jesse, just to let you know - Jerry is a poor innocent end-user running Mandriva 2009 who I directed into you guys' evil clutches, he is probably not going to be able to start running bleeding-edge kernel, Mesa, libdrm and intel git builds just to test fixes for this issue :). If a possible fix can be made available for the 2.4 branch I can build it into a test package for him, but otherwise he may not be able to help with testing much.
Hi Jesse, First, thanks for all the time you are dedicating to this. Then, I would like to ask how to pull the drm-intel tree and patch it against a kernel, since I am not very confident in using latest kernel bits. Do I have to checkout a -gitN vesion from kernel.org and the git drm-intel to patch against? Or do I just git clone the whole kernel and then git update somewhere inside a directory to update the to the latest drm-intel? Sorry for my ignorance.
Hi again, I just tried xorg from git (including xf86-video-inetl 2.5.0) on the top of linux-2.6.27-git10 (which includes the latest patches from drm-intel), and there is a similar situation as before, blank screen of course. However, the Xorg.0.log is different from the previous one, so please check out the file Xorg.0.log-2.6.27-git10, because there are many differences concerning the LVDS output and the intel driver.
Created attachment 19792 [details] Xorg.0.log-2.6.27-git10 Xorg.0.log-2.6.27-git10 with xf86-video-intel 2.5.0 and the whole Xorg from git as of 200810212320.
Hi, Same story with 2.6.28-rc1 (includes the latest patches from Airlie and E. Anholt) and the today's checkout from xorg-git. Please find enclosed the Xorg.0.log-2.6.28-rc1. Have a nice weekend.. P.S.- I won't without my Intel graphics :_(
Created attachment 19845 [details] Xorg.0.log-2.6.28-rc1 Xorg.0.log-2.6.28-rc1 (latest patches for i915) + whole Xorg from git as of 200810241039.
Good Evening guys, I use a Sony Vaio SR19XN and have same problems as described here. Graphic works fine on an external display with full Desktop Effect support. The Display of the Notebook only works using VESA drivers. I am currently using the Intrepid RC released today. Following interested your comments for further solutions. Greets Raphael
Hi again, For what is worth, I installed FreeBSD 7.1-BETA2-amd64 on my Vaio SR11M, which runs a xserver-1.4.2 with intel-2.4.2. The result is the same. This clearly remarks the fact that the Linux kernel has not much to do with this bug, and it is obviously a missing quirk for the very LVDS of this laptop series. To fix the bug, I would even risk sending my laptop overseas, keep it in mind. How can we know how to add such a quirk? I have been reading commit logs where quirks are added, and they seem very simple, since the only necessary thing is adding the hardware ID for the LVDS. Any ideas?
Hi, Here is more information, although a little bit Off-Topic. I plugged an external monitor (through VGA) to perform some tests, but the results made me quite sad, since the GM45 should outperform many old graphics cards, but it doesn't, take a look at this: ATI Radeon 9600 M10: glxgears -> 1900FPS Intel GM45: glxgears -> 680FPS ATI Radeon 9600 M10: quake3 timedemo -> 127FPS Intel GM45: quake3 timedemo -> 73FPS I just read information from the Intel site and the benchmarks list at notebookcheck.com and the GM45 should be much better than the Radeon 9600 M10, but it doesn't seem to be like that. So, besides the LVDS problem, I am also worried that the performance of the GM45 is not what I was expecting from the product details. Does anyone else have this poor performance? Is this poor performance due to the current drivers and the lack of support?
(In reply to comment #83) > Hi, > > Here is more information, although a little bit Off-Topic. I plugged an > external monitor (through VGA) to perform some tests, but the results made me > quite sad, since the GM45 should outperform many old graphics cards, but it > doesn't, take a look at this: > > ATI Radeon 9600 M10: glxgears -> 1900FPS > Intel GM45: glxgears -> 680FPS > > ATI Radeon 9600 M10: quake3 timedemo -> 127FPS > Intel GM45: quake3 timedemo -> 73FPS > > > I just read information from the Intel site and the benchmarks list at > notebookcheck.com and the GM45 should be much better than the Radeon 9600 M10, > but it doesn't seem to be like that. > > So, besides the LVDS problem, I am also worried that the performance of the > GM45 is not what I was expecting from the product details. Does anyone else > have this poor performance? > > Is this poor performance due to the current drivers and the lack of support? > I found it interesting that when I couldn't get the Intel 2.4.2 driver to load the X4500 (G45) chip on this Sony I tried several others and found that when I used the Xorg|vesa driver I appeared to get some form of acceleration! Both gears and glxgears gives me about 1300FPS, which is fast enough to run Google or Stellarium without much of a problem, although it is not fast enough to run SecondLife adequately. I wasn't aware that the VESA driver could give an accelerated screen so perhaps this points to another aspect of the problem?
Hi, Today I purchased a new Sony Vaio VGN-SR11M, and I'm experiencing the same issue with the graphic drivers. this problem exist with kernel 2.6.27.4 and intel 2.5.0 drivers. my laptop display works only using the vesa drivers. tested with Fedora 10 (rawhide) on a x86_64 installed machine: kernel-2.6.27.4-61.fc10.x86_64 xorg-x11-drv-i810-2.5.0-1.fc10.x86_64 I'm experiencing an other bug (related?) too: if I hot connect external TFT monitor, the system crash completely, reboot needed. if I power-on the laptop with monitor already connected, the system boot cleanly and the external monitors works with intel drivers too, but if I hot remove the monitor vga cable, the system hang. let's me know if you need others info. Best Regards
Created attachment 19963 [details] [review] gm45-quirk-sony-vaio-vgn-sr11m.patch Hi, today I looked more deeply into LVDS blank display problem, I checked out latest release of xf86-video-intel: git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel compiled and installed without problems, but the laptop display continue to not works. I also tried all available quirks into src/i830_quirks.c, (to demonstrate that my laptop get recognised by i831_quirks I made and attached a patch that disable completely LVDS for the VGN-SR11M model, but xorg doesn't start any more of course... so it's very useless :)) in order I tried: quirk_ignore_tv quirk_ignore_lvds quirk_ignore_macmini_lvds quirk_pipea_force quirk_ivch_need_dvob quirk_reset_modes quirk_pfit_safe none worked. the SONY VAIO VGN-SR11M graphic driver is detected with PCI_CHIP_GM45_GM, 0x104d, 0x9033 I don't know if the problem is into src/i830_lvds.c I tried any possible and imaginable xorg.conf option (tacked from man intel). parsing out Xorg.0.log from warrning I get: cat /var/log/Xorg.0.log | grep WW (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (WW) Open ACPI failed (/var/run/acpid.socket) (Connection refused) (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00440206 to 0x00440000 (WW) intel(0): PIPEBSTAT before: status: LBLC_EVENT_ENABLE SVBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): PIPEBSTAT after: status: LBLC_EVENT_ENABLE SVBLANK_INT_ENABLE (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x24000500 to 0x22000300 (WW) intel(0): ESR is 0x00000011, page table error (WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state. (WW) SynPS/2 Synaptics TouchPad can't grab event device, errno=16 Any help here is appreciated. Best Regards.
Hi - just adding my name to the list people experiencing this issue (mine's a Sony SR19XN) I can see the thread has been dead for a few days - any updates from anyone? Many thanks Martin
Hi Martin, Thanks for joining the cause. I think Jesse Barnes is quite busy writing new patches for KMS (kernel mode-setting) and GEM (graphics execution manager). And that's why this thread has been inactive for several days. Please be patient, and, I hope, when Jesse has time, we can get this fixed, because the bug is very tiny, but so weird that nobody can guess what it is related with.
(In reply to comment #88) Great thank you for the update Claudio. Good luck Jesse! Martin
Thanks for your patience everyone, sounds like this is a popular type of platform. :) I still need the output from 'intel_reg_dumper' attached to this bug. It would be best if someone could start up X with a VGA monitor attached, then capture the register dump from an xterm or whatever on that window. That should tell me what the LVDS and other registers are set to... It could be that something else in our LVDS programming is off somewhere; the register dump should help me to prove or disprove that theory.
ok i'm going to do it now; i'm a sony vaio sr-19xn, the same model it has only the fingerprint reader also. will it work also for me?
arg ... for tonight i cant try this cause on my gentoo libpciaccess need xorg 1.5.2 that's masked; is there an other way to do it or i can do it only with that program? any one other can do it? claudio ? thanks
Created attachment 20197 [details] intel_reg_dumper output on SR19XN using external monitor Here is the intel_reg_dumper output running Ubuntu 8.10 with a monitor plugged in. The machine is a Sony Vaio VGN-SR19XN.
Created attachment 20198 [details] intel_reg_dumper output without monitor Here is intel_reg_dumper without any monitor plugged in, obtained using a VT.
Created attachment 20199 [details] intel_reg_dumper output using VESA driver Same machine (SR19XN) this time booted without a monitor attached, using the laptop LVDS display and the VESA driver (with some extra parameters in xorg.conf to get correct resolution).
Created attachment 20222 [details] intel_reg_dumper output on VGN-FW140E, using vesa driver on the lcd display at 1024x768 (without monitor)
Thanks for the dumps. It looks like they were captured with a driver that didn't have the clock gating fixes though. Can someone give the latest git tree a try? There have been some fixes affecting GM45 committed there recently; if they help I can spin a 2.5.x release that includes them. Other than that, the registers look pretty good, so I'm hoping one of the recently pushed fixes will end up correcting this bug.
Created attachment 20225 [details] intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), while the non-working blank screen is seen (this is with xorg from ubuntu 8.10, I'll try to checkout & build git, but have not done that before so I'll probably need a little time to check it out etc)
Created attachment 20226 [details] intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), after switching back to the console (ctrl-alt-f1)
Hi Jesse, I just compiled and tested the latest git of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel (kernel 2.6.28-rc3) but after enabling the intel driver into xorg.conf the LVDS display remain blank like previous versions. Moreover with this version I get a kernel panic (not blocking the system) into dmesg: [drm] Initialized i915 1.6.0 20080730 on minor 0 resource map sanity check conflict: 0xc0000000 0xcfffffff 0xc0000000 0xc7feffff vesafb ------------[ cut here ]------------ WARNING: at arch/x86/mm/ioremap.c:226 __ioremap_caller+0xc7/0x299() Modules linked in: i915 drm ipt_MASQUERADE xt_multiport ipt_ULOG xt_limit nf_nat_pptp nf_conntrack_pptp nf_conntrack_proto_gre nf_nat_proto_gre nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp iptable_ma ngle iptable_nat nf_nat bridge ipv6 stp bnep sco l2cap bluetooth tun fuse cpufreq_ondemand acpi_cpufreq freq_table uinput arc4 ecb iwlagn iwlcore snd_hda_intel rfkill mac80211 snd_pcm uvcvideo snd_timer snd_pag e_alloc snd_hwdep sdhci_pci sdhci snd firewire_ohci compat_ioctl32 firewire_core i2c_i801 video serio_raw mmc_core pcspkr videodev v4l1_compat battery output crc_itu_t joydev sony_laptop i2c_core sky2 cfg80211 soundcore ac [last unloaded: microcode] Pid: 2947, comm: Xorg Not tainted 2.6.28-rc3-jugin #3 Call Trace: [<ffffffff81046831>] warn_on_slowpath+0x58/0x7d [<ffffffff81030959>] ? change_page_attr_set_clr+0x136/0x304 [<ffffffff8134eb29>] ? printk+0x3c/0x43 [<ffffffff81351143>] ? _read_unlock+0x2b/0x36 [<ffffffff8102f9bb>] __ioremap_caller+0xc7/0x299 [<ffffffffa03808d6>] ? i915_gem_entervt_ioctl+0x470/0x505 [i915] [<ffffffff8102fc7f>] ioremap_wc+0x1b/0x24 [<ffffffffa03808d6>] i915_gem_entervt_ioctl+0x470/0x505 [i915] [<ffffffffa0363b85>] drm_ioctl+0x1d6/0x25e [drm] [<ffffffffa0380466>] ? i915_gem_entervt_ioctl+0x0/0x505 [i915] [<ffffffff810d4ddd>] vfs_ioctl+0x5f/0x78 [<ffffffff810d5199>] do_vfs_ioctl+0x3a3/0x3d5 [<ffffffff810d5220>] sys_ioctl+0x55/0x77 [<ffffffff8101123a>] system_call_fastpath+0x16/0x1b ---[ end trace b498a1936775def4 ]--- I don't know if it's related, but when starting xorg with intel driver using the previous stock fedora rawhide kernel 2.6.27.5 I get: i915_driver_load "failed to enable MSI" I'm using libdrm 2.4.1 and xf86-video-intel 2.5.0-trunk (updated 7 nov) my laptop is a Sony Vaio VGN-SR11M
Ok, I upgraded the libdrm to the git version and compiled a new intel_drv.so from git: git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel and the Xorg.0.log now says 'module version = 2.4.97' (was 'module version = 2.4.1'), but the behaviour is unchanged. Other notable, maybe interesting (?) changes in the Xorg.0.log are: +(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB and (II) intel(0): 0x10000000: end of aperture +(WW) intel(0): ESR is 0x00000001 +(WW) intel(0): Existing errors found in hardware state. (II) intel(0): using SSC reference clock of 100 MHz
I guess I used an older git tree than Ugo? I don't get an oops on it though, but I do get possibly interesting messages in dmesg: (the 63-66 messages are from xorg startup and 72+ after 'ctrl-alt-f1'): [ 63.686660] mtrr: no MTRR for c0000000,7ff0000 found [ 65.378118] [drm] Initialized drm 1.1.0 20060810 [ 65.383059] pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 65.383069] pci 0000:00:02.0: setting latency timer to 64 [ 65.383327] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 65.383919] [drm:i915_getparam] *ERROR* Unknown parameter 5 [ 66.379546] set status page addr 0x07fff000 [ 72.743051] [drm:i915_getparam] *ERROR* Unknown parameter 5 [ 73.502327] set status page addr 0x07fff000
Jelle, I get the oops only using the latest drm-intel kernel tree (2.6.28-rc3) from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel. however I get the opps only after first VT switch or Xorg logout. If I boot with VGA monitor connected I get Xorg full accelerated in the external monitor, and it's seem more fast/responsive on 2.6.28-rc3-drm-intel-next than kernel 2.6.27. However if I hot plug the VGA monitor after system boot, I get a hard crash of the system, reboot needed. just updated also xf86-video-intel to latest commit (Default to FULL_ASPECT panel fitting - Jesse Barnes), but LVDS remain blank.
However the latest xf86-video-intel git is marked as version 2.4.97? this is my Xorg.0.log: (II) Loading /usr/lib64/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.5.2, module version = 2.4.97 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 4.1 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel® GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 (II) Primary Device is: PCI 00@00:02:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [5] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] (II) resource ranges after probing: [0] -1 0 0xffffffff - 0xffffffff (0x1) MX[B] [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [5] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [6] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [7] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [8] -1 0 0x00000000 - 0x00000000 (0x1) IX[B] [9] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [10] 0 0 0x000003c0 - 0x000003df (0x20) IS[B]
Created attachment 20231 [details] intel_reg_dumper of Sony Vaio VGN-SR11M System: Sony Vaio VGN-SR11M Kernel: 2.6.28-rc3 x86_64 intel_reg_dumper using intel driver with external VGA monitor connected and LVDS blank
ah, 2.4.97 is what I see too when I use the intel_drv.so that I compiled from git. I'm using the latest 2.6.27-7-generic kernel that comes with ubuntu 8.10 (intrepid, 32-bit). devs: How else can we help debug this? Is there any type of documentation from Intel (or others?) about these chips? Do the register dumps have any useful info? I don't know what the registers are, but for example a register named DSPCLK_GATE_D is the same for vesa xorg and text console, but has a different value in the 'blank screen' state of the intel driver, then perhaps it's worth trying to find out why (clock gating? -> parts of the chip maybe not activated)... Or is this a totally wrong place to look? Can we make such register dumps from a working system with an alternative os?
****ck! No way. I've been more than 3 hours trying to get the Xorg compiled, and when I got it, there is some problem with a symbol in intel_drv.so and the Xorg crashes before showing anything, this is the error: /opt/gfx-test/bin/Xorg: symbol lookup error: /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so: undefined symbol: intel_bufmgr_gem_init The Xorg is 1.5.99.1 built on the top of a 2.6.28-rc4. The git pull is from 3 hours ago, that is very very fresh, with the latest drm and mesa code, including the latest patches added to xf86-video-intel during today. Really, I'm getting frustrated about this, maybe I should just sell the laptop :P Hope you guys have better luck testing these latest patches for Jesse. Good luck!
Yeah, that's annoying. xf86-video-intel depends on libdrm, which just had all its names change recently. So you'll need to: 1) update libdrm 2) rebuild Mesa 3) rebuild xf86-video-intel before things will fully work again (if you want to live on the bleeding edge anyway).
Hi Jesse, Thanks for the guidance (and the patience). Anyways, I am quite a bit fed up already. Yesterday I tried updating libdrm and rebuilding mesa and xf86-video-intel, but the compilation gives some errors, libdrm cannot be fully installed because libtool complains about directories not ending in /usr/local/lib, which I don't understand at all. For instance it says: libtool: error: install: cannot copy 'libdrm_intel.la' into a directory not ending in '/usr/local/lib' I tried building and installing both on /opt/gfx-test, where I have everything for testing, and even I tried a fresh distribution on a new partition of my laptop where there was no Xorg at all and I downloaded the whole Xorg and built from scratch, with the prefix /usr, trying to get it working there too. But also in the latter I got many errors, such as aclocal complaining about paths and libtool still complaining about directories not ending in /usr/local/lib, so I don't know anymore what to do. And since I use Debian, it will be quite a long time before I get any 2.5.x driver on the distribution package, which sets me up even more. I hope someone else is testing and is more capable of fixing this building errors with paths, and I really hope we are really close to fixing this stupid bug. Good luck and thanks again!
could someone try this modeline? Modeline "1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848 -HSync +Vsync , and please also attach your xorg.log to verify. thanks.
with vesa or intel drivers?
(In reply to comment #111) > with vesa or intel drivers? > sorry, pls try this modeline instead: "1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848 -hsync -vsync intel driver. thanks, Michael
Created attachment 20300 [details] Xorg.log with Modeline described in Comment #112
Comment on attachment 20300 [details] Xorg.log with Modeline described in Comment #112 Xorg.log with Modeline described above. Laptop Display still not working :-/
Created attachment 20301 [details] Xorg.0.log with Modeline 1280x800_60 Attached my Xorg.0.log running with Modeline "1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848 -hsync -vsync, LVDS still not working of course :-) The following errors can cause the LVDS blank problem? (WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB and these? (WW) intel(0): ESR is 0x00000011, page table error (WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE (WW) intel(0): PRB0_CTL (0x0001f001) indicates ring buffer enabled (WW) intel(0): Existing errors found in hardware state. (II) intel(0): using SSC reference clock of 100 MHz (II) intel(0): Selecting standard 18 bit TMDS pixel format. (II) intel(0): Output configuration: (II) intel(0): Pipe A is off (II) intel(0): Display plane A is now disabled and connected to pipe A. (II) intel(0): Pipe B is on (II) intel(0): Display plane B is now enabled and connected to pipe B. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output LVDS is connected to pipe B LVDS should be connected to pipe A? or B is the correct pipe?
Created attachment 20302 [details] xorg.conf used to test Modeline 1280x800_60
(In reply to comment #112) > (In reply to comment #111) > > with vesa or intel drivers? > > > > sorry, pls try this modeline instead: > > "1280x800_60" 68.88 1280 1296 1344 1410 800 816 820 848 -hsync -vsync > > intel driver. > > thanks, > Michael > I'm sorry, how about this "1280x800_60" 68.88 1280 1296 1344 1410 800 804 808 815 -hsync -vsync
Created attachment 20313 [details] Xorg.0.log with Modeline "1280x800_60" 68.88 1280 1296 1344 1410 800 804 808 815 -hsync -vsync same result: LVDS blank :-(
Created attachment 20314 [details] sony-vaio-vgn-sr11m-rom.bin If can help, I attached my Sony Vaio VGN-SR11M GM45 ROM, using the following procedure: $ cd /sys/devices/pci0000\:00/0000\:00\:02.0/ $ echo 1 > rom $ cat rom > ~/Desktop/sony-vaio-vgn-sr11m-rom.bin $ echo 0 > rom A question about display initialization: I noted that booting with external VGA connected and intel driver, the gnome-display-properties shipped with Fedora 10, detect 2 Monitor: Laptop Display and the external monitor, but, it identify my external monitor as "Laptop Display"... I don't know if this can be the cause of this bug, because the intel driver doesn't detect correctly the LVDS display?
ok. try last one: "1280x800" 68.9 1280 1292 1340 1440 800 804 807 823 +hsync +vsync thanks.
Created attachment 20320 [details] Xorg.0.log with Modeline "1280x800_60" 68.9 1280 1292 1340 1440 800 804 807 823 +hsync +vsync same results :( with Modeline "1280x800_60" 68.9 1280 1292 1340 1440 800 804 807 823 +hsync +vsync intel driver: LVDS blank display vesa driver: works good
Good news everyone: I have picture! Posting this using the intel driver working fine on my laptop display... The 'blank display' to me looks like the panel isn't active (the slow white-to-clouds change that happens when you leave it on for more than a couple of seconds looks like charge leaking from the display elements). After reading more docs, and staring at the register dumps even more and getting nowhere, I decided it might be a good idea to enable the OUTREG debugging in the driver and looking at the log... After doing that, I saw that there were multiple calls to i830SetLVDSPanelPower() changing PP_CONTROL from 1 to 0 and back (display on and off) during xorg startup... That stroke me as a little silly, so I decided to add a 'if (!on) return;' to the beginning of that function (in i830_lvds.c), recompiled and copied the driver and woa and behold: I saw the kde login prompt. My xorg crashed soon after that though (signal 11), but that may have been the result of combining the default ubuntu xorg server with the latest git intel driver (and/or that whole libdrm stuff)... So I tried the same patch to the ubuntu intrepid source package (for which Xorg.0.log says 'module version 2.4.1'), and it works too, without segfaults... Whee... Jesse, am I right in assuming that's enough info for you or other xorg devs to get this working for everyone els?
(In reply to comment #122) > Good news everyone: I have picture! Yeah! Me too! Your fix did the job here. I used the current 2.5.0 release: http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.5.0.tar.bz2 The latest git-release crashed after a few seconds, but the 2.5.0 works (for now ;)). In xf86-video-intel-2.5.0/src/i830_lvds.c, around line 390 ( before if(on) { ) a simple line if (!on) return; did the job. Thanks mate! :)
Created attachment 20365 [details] [review] intel-vaio-lvds.patch Very good work Jelle! You have found the problem! you are very very great :-) finally I can use the LVDS display with accelerated intel driver :-) I attached your suggested patch to this post. Now some xf86-intel-driver developer should be look into the code to verify if this is the right method to fix our problem and make a patch upstream :-) Thank you all for looking into this bug. Best Regards.
Thank you Jelle! A lot! And thanks for the xf86-video-intel-2.5.0 link Karsten. (it isn't patched though) I managed to get the intel driver to work on a Sony Vaio VGN-FW140E running Ubuntu 8.10. Since i am kinda a beginner in Linux I had some problems compiling/installing though. Had to install all the packages from: http://ubuntuforums.org/showthread.php?p=1646660 And then xorg couldn't find the driver module so i had to copy everything from: /usr/local/lib/xorg/modules/drivers to /usr/lib/xorg/modules/drivers weird. Anyway, it works so i'm happy. Btw, i'm getting ~700fps in glxgears. A bit low i think. Anyway, it doesn't matter:D. Thanks again, Mihai PS: get it upstream so many can enjoy it:).
Hi Jelle, Thank you very much for discovering the problem. Now we hope that Jesse can examine how this could be done without affecting the general code of the driver for the rest of workstations. Hopefully we see some patch for a Christmas present! :D Congrats again!
I just want to confirm that this fix worked for me on my Sony Vaio VGN-FW170J with kubuntu-8.10-amd64 installed I used the source package for xserver-xorg-video-intel from ubuntu repositories ( 2:2.4.1-1ubuntu10 ) and applied the patch. The display is on now. The login screen has two vertical strips with "noise" at the sides, but the display is ok once kde starts. As for the backlight, the control buttons doesn't work, it's always set to it's maximum value. The following lines are written to Xorg.0.log almost every 10 seconds: (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): I2C device "LVDSDDC_C:ddc2" removed. Although direct rendering is on, glxgears outputs: 3610 frames in 5.0 seconds = 721.848 FPS, which is way lower than what I expects from this card. X crashed when I tried to change the resolution from systemsettings.
Hello guys! I manually patched the driver (version 2.4.2-1 from Debian Sid repositories) and now it is working, although it is a little bit rudimentary and glxgears and also any GLX program show very "strange" as well as low performance. I created the .deb file for Debian Sid amd64, so if it helps, here is the link to it: http://www.claudiocamacho.org/files/xserver-xorg-video-intel_2.4.2-1_amd64.deb Meanwhile we get a proper driver release, you can try that and have some nice experiences using Xv for video playback or any GLX application :) I'll keep researching.
BTW, I just tried the 2.4.2-1 patched with a different kernel (2.6.28-rc4) and the system totally froze. So, it works with 2.6.27.5, but not with 2.6.28-rc4. Besides, glxgears shows only 60fps, while Quake 3 Arena runs nicely but only at 59fps with low detail, which should be around 100fps and more than 1500fps for glxgears. Xvideo seems to work without any major problem.
> --- Comment #129 from Claudio Camacho <claudiomkd@gmail.com> 2008-11-19 08:18:48 PST --- > Besides, glxgears shows only 60fps, while Quake 3 Arena runs nicely but only at > 59fps with low detail, which should be around 100fps and more than 1500fps for > glxgears. > if your refresh rate is 60Hz, then 60fps is expected.
fyi, I also get the 'junk' on the sides on the kde login screen (it looks like uninitialized pixels) and after logging in that's gone and the full screen is used. The display brightness hotkeys also don't work for me, but I'm not sure if that is something for this driver, because I can change it using the sys filesystem: echo 1 >/sys/class/backlight/acpi_video0/brightness
yeah I'm sorry for the backlight thing, it's definitely not the video driver's fault ( I installed xbacklight and it works )
Actually, about the refresh rate.. With my previous laptop, the refresh rate was 60Hz, but glxgears showed up to 2300fps and Quake 3 Arena was giving a 143fps peak. Now, with the Vaio LVDS, the refresh rete is set at 59.9Hz (at least using 2.6.27.5 + xserver-xorg-video-intel-2.4.2), and _everything_ shows up to 60fps. However, all glx programs and games perform well (they usually don't go below 60fps, but they don't show more either). I don't know if this is a mistake, or if I should wait for 2.5.1+2.6.28. If anyone has some information, please post it here :)
(In reply to comment #133) > Actually, about the refresh rate.. > > With my previous laptop, the refresh rate was 60Hz, but glxgears showed up to > 2300fps and Quake 3 Arena was giving a 143fps peak. > > Now, with the Vaio LVDS, the refresh rete is set at 59.9Hz (at least using > 2.6.27.5 + xserver-xorg-video-intel-2.4.2), and _everything_ shows up to 60fps. > However, all glx programs and games perform well (they usually don't go below > 60fps, but they don't show more either). I don't know if this is a mistake, or > if I should wait for 2.5.1+2.6.28. > > If anyone has some information, please post it here :) > glxgears "fps" are dependent on the size of the window in which the gears are displaying. If I shrink that window to the smallest it can be my "fps" rate goes up to around 2800. If I make that window the full size of my display it drops to only 68 "fps" and the wheels do not rotate smoothly. I am presently using XOrg's vesa driver to get by until this blank screen solution is passed down to the users. Supposedly, vesa isn't supposed to offer acceleration and glxgears should not work at all. The MCC display configuration tool says that 3D is not available, yet I get good performance on GoogleEarth and sluggish but acceptable performance on Stellarium.
(In reply to comment #133) > Actually, about the refresh rate.. > > With my previous laptop, the refresh rate was 60Hz, but glxgears showed up to > 2300fps and Quake 3 Arena was giving a 143fps peak. > > Now, with the Vaio LVDS, the refresh rete is set at 59.9Hz (at least using > 2.6.27.5 + xserver-xorg-video-intel-2.4.2), and _everything_ shows up to 60fps. > However, all glx programs and games perform well (they usually don't go below > 60fps, but they don't show more either). I don't know if this is a mistake, or > if I should wait for 2.5.1+2.6.28. > > If anyone has some information, please post it here :) > As Julien said, 60fps is expected. http://intellinuxgraphics.org/community_testing.html lists this issue: - vblank: the new mesa code changes the default setting to sync'ing to vblank. So now it's not a surprise to see glxgears reports 60FPS. But this introduces some bugs (like bug#17967), and setting vblank_mode back to 0 works around it.
*** Bug 18582 has been marked as a duplicate of this bug. ***
(In reply to comment #134) > glxgears "fps" are dependent on the size of the window in which the gears are > displaying. If I shrink that window to the smallest it can be my "fps" rate > goes up to around 2800. If I make that window the full size of my display it > drops to only 68 "fps" and the wheels do not rotate smoothly. This is a common problem with these intel chipset, from what i've been told it is a problem with the memory preassure with a large amount of writes to the backbuffer. I.e. the card has power, but the memory bus can't keep up. There are supposed to be feature supported by the chipset which supposedly should improve this, but it's not yet implemented in the intel linux drivers. Supposedly it is in the windows drivers, but i've not been able to find any better performance there. I've not tested that much thou.
Hello again, I just tried xf86-video-intel-2.5.1 on Debian Sid, using the dirty patch on i830_lvds.c, and I was using the kernel 2.6.28-rc6, to try how the performance is (due to the GEM). However, I noticed that Xorg crashes after 5 minutes of usage. In fact, any GLX application (TORCS, Quake3, or even KDE4 OpenGL composite manager) will make the Xorg crash in a few minutes. The mouse can be moved, but the rest of the screen and they keyboard are frozen. Please notice that using 2.6.27 + xf86-video-intel-2.5.1 is not a problem at all, so this is related to the GEM and therefore out of this topic, but I just mention it here, since we are talking about the GM45. I hope we can see some real patch soon.
(In reply to comment #138) Actually, I have this issue with Fedora 10 (while running kwin's compositor), which is running a 2.6.27 kernel, so it might not be GEM related (unless Fedora brought GEM back to 2.6.27...). I haven't had the issue in Kubuntu 8.10 or Mandriva 2009 though, which use the 2.4 driver, so maybe it's just 2.5 in general?
Claudio, it sounds like your crashes are probably a separate bug from this one, please file a new bug with all the info you can collect. As for Ugo's patch, it definitely provides an important clue here: it looks like touching the panel registers (at least the way we do) on this platform can cause bad behavior. So I don't think the patch is perfect as-is, but it will definitely help us come up with a more complete fix. I'm pulling down the latest docs now to see what might be the problem in this code path. There could be a problem in the way we turn off the panel, or maybe in the way we try to turn it back on, hopefully I'll know more after reading over things.
(In reply to comment #140) > As for Ugo's patch, it definitely provides an important clue here: it looks > like touching the panel registers (at least the way we do) on this platform can > cause bad behavior. So I don't think the patch is perfect as-is, but it will > definitely help us come up with a more complete fix. I'm pulling down the > latest docs now to see what might be the problem in this code path. > > There could be a problem in the way we turn off the panel, or maybe in the way > we try to turn it back on, hopefully I'll know more after reading over things. Jesse, thank you very much in looking deeper on this bug.
Ok Jesse, I just have to thank you for taking so much time in discovering how to fix this bug, and I will experiment with 2.6.28-rc6 + 2.5.1 in order to place a new bug for this GLX crashes. Please, remember to ask from us anything you might need, because I feel quite useless since I don't have any knowledge that could apply in fixing this bug. Thanks once again and good luck.
Created attachment 20587 [details] [review] delay after panel off On the theory that we're not waiting long enough after the panel powers off before turning it on again, this patch adds a delay after the panel off sequence. Can someone give it a try? It looks like the PP_DIVISOR we're using doesn't match what's in the VBIOS, so if this patch works we can try using a different value there...
Hi Jesse, I just tried with the delay (usleep()) and it doesn't help. The LVDS takes longer to "initialize" (until the backlight is ON), however the blank screen is there. But, obviously, the problem is with the LVDS and concretely with the LVDSPanelPower() function, and I am glad that this is getting closer and closer. Thank you very much for your efforts.
Thanks Guys I had this problem on my sony VGN-FW248J using Ubuntu & Fedora after finding your posts I compiled DRM from GIT and downloaded the xf86-video-intel-2.5.1 and added the if(!no) return; around line 390 and compiled. moved modules from /usr/local/lib/xorg/modules/drivers to /usr/lib/xorg/modules/drivers also had to move /usr/local/lib/libdrm_intel.* to /usr/lib/ now all seems to work. glxgears is giving me 753.566 FPS Thanks
(In reply to comment #143) > Created an attachment (id=20587) [details] > delay after panel off > > On the theory that we're not waiting long enough after the panel powers off > before turning it on again, this patch adds a delay after the panel off > sequence. Can someone give it a try? > > It looks like the PP_DIVISOR we're using doesn't match what's in the VBIOS, so > if this patch works we can try using a different value there... > First of all: thanks for your work Jesse! But this patch doesn't fix the bug. I also tried to increase the value to "1500*500" - still nothing. But i noticed the following: When starting the X-server, the screen turns off completely. And with your patch it stays off even longer. And with my increased value - you guessed it - it's off even longer. But after that time the panel is switched on again (the backlight gets activated), but the screen remains black. So to me, this timeout-thing is not the problem. But I'm not really an expert in what you guys are doing there :D
Adding to CC so I can track Mdv bug: https://qa.mandriva.com/show_bug.cgi?id=45427
I'm also seeing the "gray-screen" bug, Sony Vaio VGN-FW190 w/ Intel GMA 4500MHD. Going to try and apply the fix, to see if it works.
Jesse, I don't think the problem is that the panel is powered on or off to fast, but it's doing it too often. The panel is already on when xorg starts up, but still I saw multiple calls to i830SetLVDSPanelPower() to turn it on, off, on, off, on, etc... The problem is probably caused by doing that at all, not by doing it too fast. Why turn it off if you're going to turn it back on in a few microseconds (milli?) anyway?
changing summary title back ('checking for DRM' does not describe the issue better)...
Well, yes, we do power the panel up and down more than we should, but as long as we do it correctly we should be able to do it all day w/o glitches. Also, in order to change modes, the panel generally has to be off, so we really do need to cycle it. On GM45 chips, there's a new bit to indicate when the other panel related registers are all set up, meaning that the panel can be turned on. We don't check it yet and that could be a problem. The (untested, still messing with my GM45 machine) patch below tries to do that; no idea if it'll have any effect though... diff --git a/src/i810_reg.h b/src/i810_reg.h index e2ffba1..912f042 100644 --- a/src/i810_reg.h +++ b/src/i810_reg.h @@ -896,6 +896,7 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. #define PP_STATUS 0x61200 # define PP_ON (1 << 31) +# define PP_ASSETS_READY (1 << 30) /* GM45+ */ /** * Indicates that all dependencies of the panel are on: * diff --git a/src/i830_lvds.c b/src/i830_lvds.c index 239bc89..3f79b29 100644 --- a/src/i830_lvds.c +++ b/src/i830_lvds.c @@ -403,6 +403,16 @@ i830SetLVDSPanelPower(xf86OutputPtr output, Bool on) dev_priv->backlight_duty_cycle == 0) dev_priv->backlight_duty_cycle = dev_priv->backlight_max; + /* + * On G45+ we should wait for "asset status" before turning on the + * panel + */ + if (IS_GM45(pI830)) { + do { + pp_status = INREG(PP_STATUS); + } while (!(pp_status & PP_ASSETS_READY)) + } + OUTREG(PP_CONTROL, INREG(PP_CONTROL) | POWER_TARGET_ON); do { pp_status = INREG(PP_STATUS);
Oh, asset ready is an old bit actually, but it's still worth looking at.
That one didn't seem to work for me. I started from a fresh source, applied the patch (added the semicolon in the 'while' line), build, install, and restart xorg, and the 'clouds' effect was back. I double-checked with md5sum that I was using the intel_drv.so that I just built with that patch. xorg did startup a little slower (black screen laster just a little longer), but the bug was still there.
Looking at the dumps again, two things stick out between the working vesa case and the broken intel case: --- sony-panel.fail 2008-12-18 12:11:52.000000000 -0800 +++ sony-panel.vesa 2008-12-18 12:12:05.000000000 -0800 @@ -25,7 +25,7 @@ (II): DVOC_SRCDIM: 0x00000000 (II): PP_CONTROL: 0x00000001 (power target: on) (II): PP_STATUS: 0xc0000008 (on, ready, sequencing idle) -(II): PFIT_CONTROL: 0xa0000000 +(II): PFIT_CONTROL: 0x20000000 (II): PFIT_PGM_RATIOS: 0x08000800 (II): PORT_HOTPLUG_EN: 0x00000120 (II): PORT_HOTPLUG_STAT: 0x00000000 @@ -76,7 +76,7 @@ (II): VCLK_DIVISOR_VGA0: 0x00031108 (II): VCLK_DIVISOR_VGA1: 0x00031406 (II): VCLK_POST_DIV: 0x00020002 -(II): VGACNTRL: 0x22c4008e (enabled) +(II): VGACNTRL: 0xa2c4008e (disabled) (II): TV_CTL: 0x00000010 (II): TV_DAC: 0x70000000 (II): TV_CSC_Y: 0x00000000 So both the VGA plane and panel fitting are enabled. Neither should be in this case, so that's one bug. Jelle, can you capture dumps both with and w/o your patch? Since some registers should be locked with your patch applied we can see what else might be changing...
Ok, the dump without my patch is the attachment id=20225 that I added here on 2008-11-11 12:59 PST " intel_reg_dumper output on VGN-FW140E, using intel driver on the lcd display at 1600x900 (without monitor), while the non-working blank screen is seen", filename intel_reg_dumper-vgn-fw140e-intel-1600-900-white.txt I'll add the dump output of my current, working screen (with the 'if(!on)' hack) next. Here is the diff btw: $ diff -U0 intel_reg_dumper-vgn-fw140e-intel-1600-900-w*txt --- intel_reg_dumper-vgn-fw140e-intel-1600-900-white.txt 2008-11-11 15:49:22.000000000 -0500 +++ intel_reg_dumper-vgn-fw140e-intel-1600-900-working_ifnotonhack.txt 2008-12-18 23:40:03.000000000 -0500 @@ -12 +12 @@ -(II): SDVOC: 0x00000898 (disabled, pipe A, stall disabled, not detected) +(II): SDVOC: 0x00000018 (disabled, pipe A, stall disabled, not detected) @@ -22 +22 @@ -(II): DVOC: 0x00000898 (disabled, pipe A, no stall, +hsync, +vsync) +(II): DVOC: 0x00000018 (disabled, pipe A, no stall, +hsync, +vsync) @@ -30 +30 @@ -(II): PORT_HOTPLUG_EN: 0x38000120 +(II): PORT_HOTPLUG_EN: 0x38000020 @@ -32,2 +32,2 @@ -(II): DSPACNTR: 0x58000400 (disabled, pipe A) -(II): DSPASTRIDE: 0x00001a00 (6656 bytes) +(II): DSPACNTR: 0x00000000 (disabled, pipe A) +(II): DSPASTRIDE: 0x00000000 (0 bytes) @@ -37 +37 @@ -(II): DSPASURF: 0x00100000 +(II): DSPASURF: 0x00000000 @@ -41,2 +41,2 @@ -(II): PIPEASTAT: 0x00020206 (status: VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS) -(II): FPA0: 0x00021108 (n = 2, m1 = 17, m2 = 8) +(II): PIPEASTAT: 0x00020000 (status: VBLANK_INT_ENABLE) +(II): FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8) @@ -44,8 +44,8 @@ -(II): DPLL_A: 0x14800000 (disabled, non-dvo, default clock, DAC/serial mode, p1 = 8, p2 = 10) -(II): DPLL_A_MD: 0x00000000 -(II): HTOTAL_A: 0x033f027f (640 active, 832 total) -(II): HBLANK_A: 0x033f027f (640 start, 832 end) -(II): HSYNC_A: 0x02bf0297 (664 start, 704 end) -(II): VTOTAL_A: 0x020701df (480 active, 520 total) -(II): VBLANK_A: 0x020701df (480 start, 520 end) -(II): VSYNC_A: 0x01ea01e8 (489 start, 491 end) +(II): DPLL_A: 0x04020c00 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 2, p2 = 10) +(II): DPLL_A_MD: 0x00000003 +(II): HTOTAL_A: 0x031f027f (640 active, 800 total) +(II): HBLANK_A: 0x03170287 (648 start, 792 end) +(II): HSYNC_A: 0x02ef028f (656 start, 752 end) +(II): VTOTAL_A: 0x020c01df (480 active, 525 total) +(II): VBLANK_A: 0x020401e7 (488 start, 517 end) +(II): VSYNC_A: 0x01eb01e9 (490 start, 492 end) @@ -63,2 +63,2 @@ -(II): PIPEBSTAT: 0x00020246 (status: VBLANK_INT_ENABLE VSYNC_INT_STATUS LBLC_EVENT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS) -(II): FPB0: 0x00021007 (n = 2, m1 = 16, m2 = 7) +(II): PIPEBSTAT: 0x00020000 (status: VBLANK_INT_ENABLE) +(II): FPB0: 0x00021107 (n = 2, m1 = 17, m2 = 7) @@ -66,2 +66,2 @@ -(II): DPLL_B: 0x98026000 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14) -(II): DPLL_B_MD: 0x00000000 +(II): DPLL_B: 0x98026c00 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 2, p2 = 14) +(II): DPLL_B_MD: 0x00000003 @@ -69 +69 @@ -(II): HBLANK_B: 0x0665063f (1600 start, 1638 end) +(II): HBLANK_B: 0x065f063f (1600 start, 1632 end) @@ -114 +114 @@ -(II): FBC_CFB_BASE: 0x00020000 +(II): FBC_CFB_BASE: 0x00000000 @@ -116,2 +116,2 @@ -(II): FBC_CONTROL: 0x20000080 -(II): FBC_COMMAND: 0x08c80032 +(II): FBC_CONTROL: 0x00000000 +(II): FBC_COMMAND: 0x00000000 @@ -120 +120 @@ -(II): FBC_FENCE_OFF: 0x4d006900 +(II): FBC_FENCE_OFF: 0x00009200 @@ -147,4 +147,2 @@ -(II): SDVO phase shift 0 out of range -- probobly not an issue. -(II): pipe A dot 31500 n 2 m1 17 m2 8 p1 8 p2 10 -(II): SDVO phase shift 0 out of range -- probobly not an issue. -(II): pipe B dot 88392 n 2 m1 16 m2 7 p1 2 p2 14 +(II): pipe A dot 100800 n 3 m1 17 m2 8 p1 2 p2 10 +(II): pipe B dot 92857 n 2 m1 17 m2 7 p1 2 p2 14
Created attachment 21291 [details] intel_reg_dumper on working lcd with if(!on) hack intel_reg_dumper on working lcd with if(!on) hack note: this is after a restore from suspend to ram (which works fine btw).
Created attachment 21320 [details] Failing log of Sony VAIO VGN-FW235 with intel driver and LVDS screen (4500MHD) To be honest, I'm not sure what this means. I applied the previously suggested patches and compiled, and now instead of the white screen with grey blobs, the screen is shut off completely. The keyboard becomes unresponsive, and the screen won't turn back on, but I can still access the computer via SSH and, for instance, change the backlight brightness.
I've seen a black screen once or twice too, but I don't remember the exact circumstances to trigger it. Don't know if it's the same you saw, but I've always been able to get the picture back by switching to vc1 (ctrl-alt-f1), where you see the text login prompt, then back to vc7 (alt-f7).
(In reply to comment #158) > I've seen a black screen once or twice too, but I don't remember the exact > circumstances to trigger it. Don't know if it's the same you saw, but I've > always been able to get the picture back by switching to vc1 (ctrl-alt-f1), > where you see the text login prompt, then back to vc7 (alt-f7). > X itself crashes, but it never turns the screen back on so I'm basically stuck with the blank screen until I reboot. One time it magically came back on tty1 but I haven't been able to reproduce that.
(In reply to comment #159) > (In reply to comment #158) > > (In reply to comment #157) Disregard all of this, after some debugging I found it was an issue with mesa. The laptop works great, 70FPS in glxgears, and I'm very grateful for the patches Jesse made. :)
So can you narrow down which patch makes things work for you? I know Jelle's patch will work around the brokenness, but I'd like to find a fix that allows us to correctly power up/down the panel.
Created attachment 21526 [details] [review] Try LVDS write protect Over 150 comments is horrible. What I can see from this problem is LVDS can't be lighten up. So here's a patch trying to turn write protect off before modesetting, and on after it. I'd like to make it a big hammer patch as so many patches flowing around here, but it might be missing Jesse's patch in comment #151. Please take a fresh driver and test with this one.
*** Bug 17508 has been marked as a duplicate of this bug. ***
I tried i830-lvds-write-protect-test.patch on ubuntu intrepid and it does not fix the bug (looks completely unchanged to me). PS: the first chunk got rejected by patch, because the "RestoreHWState(pScrn);" line already isn't there in that version (2.4.1).
Created attachment 21544 [details] [review] The only known way to work around this bug... Use: Option "lvdshack" "True" Since the real fix for this bug has been elusive, I hereby attach a patch for the only known way to make this driver work on this hardware. I added it as an xorg.conf option that is default off. The hack only gets activated when you add the line Option "lvdshack" "True" in the 'Device' section of your /etc/X11/xorg.conf Perhaps the distro maintainers, for now, can temporarily include this patch in their builds, so that end users can at least use the 3d accelerated intel driver on their laptops after a relatively simple xorg.conf edit... (patch is against xserver-xorg-video-intel-2.4.1 from Ubuntu 8.10).
Wang, thanks for the attempt but i've tried the patch too on the 2.5.1 and it does not work =( . I give the same black lightened screen.
Perhaps interesting is the difference in the Xorg.0.log with the hack disabled/enabled: Without the hack (display 'clouds', unusable): (II) intel(0): Comparing regs from server start up to After PreInit (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x80020206 to 0x00020206 (WW) intel(0): PIPEBSTAT before: status: FIFO_UNDERRUN VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): PIPEBSTAT after: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to 0x4d003800 (==) Depth 24 pixmap format is 32 bpp With the hack (display working fine): (II) intel(0): Comparing regs from server start up to After PreInit (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00020206 to 0x80020206 (WW) intel(0): PIPEBSTAT before: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VBLANK_INT_ENABLE VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to 0x4d003800 (==) Depth 24 pixmap format is 32 bpp What I found interesting is that the PIPEBSTAT before and after appear swapped... I haven't tried to find out what that means, but perhaps it rings a bell for one of you guys? Maybe it also matters that when it's working it doesn't say that PP_STATUS has changed?
(In reply to comment #167) > Without the hack (display 'clouds', unusable): > (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to > 0xd000000a > (WW) intel(0): PP_STATUS before: on, ready, sequencing idle > (WW) intel(0): PP_STATUS after: on, ready, sequencing on > (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x80020206 to > 0x00020206 > (WW) intel(0): PIPEBSTAT before: status: FIFO_UNDERRUN VBLANK_INT_ENABLE > VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS > (WW) intel(0): PIPEBSTAT after: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS > SVBLANK_INT_STATUS VBLANK_INT_STATUS > (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to > 0x4d003800 > (==) Depth 24 pixmap format is 32 bpp > > With the hack (display working fine): > (WW) intel(0): Register 0x71024 (PIPEBSTAT) changed from 0x00020206 to > 0x80020206 > (WW) intel(0): PIPEBSTAT before: status: VBLANK_INT_ENABLE VSYNC_INT_STATUS > SVBLANK_INT_STATUS VBLANK_INT_STATUS > (WW) intel(0): PIPEBSTAT after: status: FIFO_UNDERRUN VBLANK_INT_ENABLE > VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS > (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x00009300 to > 0x4d003800 > (==) Depth 24 pixmap format is 32 bpp > > What I found interesting is that the PIPEBSTAT before and after appear > swapped... I haven't tried to find out what that means, but perhaps it rings a > bell for one of you guys? Maybe it also matters that when it's working it > doesn't say that PP_STATUS has changed? Well we'd expect PP_* to be different, since with the hack applied the panel status no longer changes at server startup time. The PIPEBSTAT changes are a bit of a concern though; it normal operation I'd expect to see one FIFO_UNDERRUN, so this could be normal (and earlier comments indicated that the bug causing flood of "pipe b underrun" messages has been fixed), but it could also be part of the problem. Do you still see the flood of underrun errors in your log?
"Do you still see the flood of underrun errors in your log?" No I don't see that, nor do I think I ever saw them.
I tried to reproduce this on my T61 (older chipset, but should still be possible since it really seems related to panel startup) but wasn't able to, even after really messing with the setpanelpower function. However, in looking at the old i915 docs, it seems that we don't actually need to power off the panel in most cases. There are only two cases where it's really necessary: when coming from a native VGA mode or when coming from a centered VGA mode with panel fitting enabled. Neither of these seem to be common default configurations, so we may be able to use something like Jelle's patch, but it'll need to check for those two conditions before refusing to power off the panel. I'd still like to understand the root cause better though too, so I'll ping the chipset guys while I spin a new patch.
Created attachment 21567 [details] [review] avoid power cycling the panel at startup In many cases, we don't actually have to shut down the panel. This patch tries to avoid it the most common case: mode setting at startup. We still need to cycle sometimes though, like when we change panel fitting status or mode timings. This doesn't address the DPMS issue though; in that case your panel will still go off and probably not come back (still talking with the chipset guys about that).
I tried that latest patch, Jesse. It doesn't work with that patch, but it does change the behavious a little bit. When starting X from a console vt, it now first looks a little different (more grey, some specks, and some dotted-vertical lines), then goes on to the exact same effect as without any patches.
Happy new 2009, and bad news guys! I was quiet since I though that maybe KMS would bring some changes to this situation. I just tried 2.6.28-git14 (which already included the KMS patches) along with xf86-video-intel 2.5.1. The situation now is ugly. The kernel boots normally (all the messages are seen on the console with my Debian), but when the display manager (slim, in my case) starts, the screen goes off, then on, but it remains blank, just like at the beginning of this bug. I tried 2.5.1 both with the hack (if (!on) return) and without it, and the situation is the same. The X server doesn't crash, since I am able to log in, to change to the console VT and perform commands, however the screen is blank all the times, so I am afraid we have the problem even bigger now with KMS. I attach now the dmesg and the Xorg.log.0, so you can analyze them. I hope someone knows why KMS brought this issue.
Created attachment 21873 [details] 2.6.28-git14 KMS dmesg
Created attachment 21874 [details] 2.6.28-git14 (KMS) + Xorg 7.4 By the way, I forgot to list the versions of my packages I am using for libdrm and mesa, just in case, here they are: libdrm-intel1 2.4.3+git+20090105+a8c5480-1 libdrm2 2.4.3+git+20090105+a8c5480-1 libgl1-mesa-dri 7.2+git20081209.a0d5c3cf-0ubuntu4 libgl1-mesa-glx 7.2+git20081209.a0d5c3cf-0ubuntu4 mesa-utils 7.2+git20081209.a0d5c3cf-0ubuntu4 xserver-xorg 7.4~4 xserver-xorg-core 1.5.3-1 xserver-xorg-video-intel 2.5.1-1 I hope this clarifies things out.
By the amount of guesswork being done the dev guys are obviously having trouble getting the GM45 chipsets to work. This is supposed to be an Intel supported chipset. Isn't Intel supplying specification details to Linux developers that explain how the display is turned on and off, and other critical details? Or, is this primarily a Sony problem? http://intellinuxgraphics.org/download.html
It's definitely a driver problem, but panel power sequencing can be tricky. Some panels are more picky than others; and in this case Sony didn't really care of Linux worked out of the box before they shipped, so they didn't do any testing, validation or bug fixing beforehand. I'm talking with our hardware folks about how we might improve our panel power sequencing code, and we have some similar bugs open against a few other platforms (like #18342); I'm hoping they share the same root cause. Unlike this bug though, Dell is actively involved in 18342 and have just sent me some of the problematic hardware. But as usual, bug your platform vendor when Linux stuff doesn't work well. They're in the best position to change their processes and make sure things work well at ship time.
I also upgraded to ubuntu jaunty, which runs newer xorg and 2.6.28 kernel, and I did get is to work, with a similar patch as the last one I posted here ('option lvdshack'). It didn't work with libdsm 2.4.3, and xorg now crashes right after coming back from a suspend (I see the screenlock password dialog, then it crashes). So while that's also a step backwards in usability, it's not yet completely unusable ;-)... I hope they figure this out soon. These are my package versions (the xserver-xorg-video-intel is a patched one with the 'if (!on)' hack... $ uname -r ; dpkg -l libdrm-intel1 libdrm2 libgl1-mesa-dri libgl1-mesa-glx mesa-utils xserver-xorg xserver-xorg-core xserver-xorg-video-intel 2.6.28-4-generic Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==========================-==========================-==================================================================== ii libdrm-intel1 2.4.1-0ubuntu9 Userspace interface to intel-specific kernel DRM services -- runtime ii libdrm2 2.4.1-0ubuntu9 Userspace interface to kernel DRM services -- runtime ii libgl1-mesa-dri 7.2+git20081209.a0d5c3cf-0 A free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-glx 7.2+git20081209.a0d5c3cf-0 A free implementation of the OpenGL API -- GLX runtime ii mesa-utils 7.2+git20081209.a0d5c3cf-0 Miscellaneous Mesa GL utilities ii xserver-xorg 1:7.4~5ubuntu9 the X.Org X server ii xserver-xorg-core 2:1.5.99.3-0ubuntu4 Xorg X server - core server ii xserver-xorg-video-intel 2:2.5.1-1ubuntu7 X.Org X server -- Intel i8xx, i9xx display driver
Additional note to my last posting, xorg does not crash when coming back from suspend when compositing is off, and with it on (and only then), I sometimes see the contents of (parts of) the wrong windows. So, all that may all be related to the recent graphical memory management changes. So, in summary the 'lvdshack' still works for me with 2.6.18 and the 2.5.1 intel driver, as long as I don't use compositing, and the issues with compositing are probably not relevant for this particular bug.
Hi, I've been reading (after my frustration) on the error I get in the Xorg.0.log with KMS enabled in 2.6.29-rc1, and I found that usually this error is due to the fact that old monitors do not support as big resolution as it is specified in the xorg.conf. However, in this case, I have an empty xorg.conf (since I use i915), and I don't understand why this happens. Moreover, if I disable the KMS by default, then 2.6.29-rc1 boots normally, but the Xorg is not accelerated (glxinfo | grep render, this returns Software Rasterizer), since glxgears shows 150fps and the CPU gets to 100%. Further, if I try to run 2.6.28 with 2.5.1 using libdrm-2.4.3 + mesa 7.3rc1, any GLX application gives segmentation fault. I guess this does not belong to this bug. The important thing here is that why KMS-enabled kernel cannot give any screen and therefore Xorg fails to show anything on the screen, and hence the VTs get blank also (since KMS makes everything graphical). P.S.- I haven't tried 2.6.0-rc2 yet (no way to get it compiled in Debian).
Jelle and Claudio, can you guys file separate bugs for your KMS and acceleration problems? I don't want to make this one any bigger than it already is! :)
Created attachment 21910 [details] [review] Make sure h & vblank end come *after* h & vsync end Can you give this a try? Seems to fix #18342 for me.
Hi Jesse, Thanks for that patch. My Xorg was fine anyway, but I've noticed something with the H & Vblank patch. Only when using KDM (slim and GDM were OK), before, I got black and white stripes (I don't know if it really relates #18342, because there they say the screen was unusable, and I could use it since the stripes went away after login) before KDM was initiated. Now with this patch, GDM and slim are still the same (everything OK) and the white stripes before KDM are gone. However, when logging in, there is a time where the screen gets black (and some dirt on the top) and then I see the desktop (maybe it has to do with the fact that I don't use KDE fully, but KDM to test the patch and then Openbox at login, I don't know). To sum up, this patch didn't hurt my Xorg, and it got rid of the white stripes before KDM start, so the patch is functional. I tested it with 2.6.29-rc1 (KMS disabled), mesa 7.3rc1 and libdrm 2.4.3. On what it respects to GEM+KMS, I will check a couple of things more and soon I will create a new bug report to see if this DRM problem can get fixed, sorry for mixing up here, it must be frustration :-/ Thank you once again.
(In reply to comment #183) > Thanks for that patch. My Xorg was fine anyway, but I've noticed something with > the H & Vblank patch. > > Only when using KDM (slim and GDM were OK), before, I got black and white > stripes (I don't know if it really relates #18342, because there they say the > screen was unusable, and I could use it since the stripes went away after > login) before KDM was initiated. Claudio, thanks for testing. Just to confirm: you applied my patch to an unmodified xf86-video-intel and the panel came up correctly? > On what it respects to GEM+KMS, I will check a couple of things more and soon I > will create a new bug report to see if this DRM problem can get fixed, sorry > for mixing up here, it must be frustration :-/ No worries, thanks. :) We like to keep issues separated to make testing & tracking easier. Jelle, have you had a chance to check out my patch?
> Claudio, thanks for testing. Just to confirm: you applied my patch to an > unmodified xf86-video-intel and the panel came up correctly? No, I applied the patch to xf86-video-intel-2.5.1 with the previous hack (if (!on) return;) from Jelle. I mean, I did the hack plus your new patch. Therefore, the panel lights up properly, but due to the old hack.
GREAT NEWS EVERYBODY!!! (In reply to comment #185) > > Claudio, thanks for testing. Just to confirm: you applied my patch to an > > unmodified xf86-video-intel and the panel came up correctly? Actually!!! I removed the if (!on) return; hack, and it still comes up correctly. I mean, if you take an unmodified xf86-video-intel-2.5.1 and patch with your h&vblank patch, the panel comes up properly in my Vaio SR11M. I cannot believe that this day has come! Jesse you are a genius!! I am quite happy right now. I hope this patch is definitive and can go into 2.6.0. Please if you read this message, tell me as soon as possible if I should test something else, so that we can clear out that it works in general for every display and hence you can enter it into the upcoming 2.6.0. Yeeeeahhh! Thank you very very much for all the work everybody has done here! I cannot explain how happy I am just now (: Now I'm going to test DRM stuff with KMS and put another bug report for the Mesa people (:
(In reply to comment #186) > GREAT NEWS EVERYBODY!!! > > (In reply to comment #185) > > > Claudio, thanks for testing. Just to confirm: you applied my patch to an > > > unmodified xf86-video-intel and the panel came up correctly? > > Actually!!! I removed the if (!on) return; hack, and it still comes up > correctly. I mean, if you take an unmodified xf86-video-intel-2.5.1 and patch > with your h&vblank patch, the panel comes up properly in my Vaio SR11M. > > I cannot believe that this day has come! Jesse you are a genius!! Excellent, thanks a lot for testing. > I am quite happy right now. I hope this patch is definitive and can go into > 2.6.0. If it doesn't make it into 2.6.0 it'll be in 2.6.1. But at least I know what the problem is now (having some hardware w/this problem helps :)... > Now I'm going to test DRM stuff with KMS and put another bug report for the > Mesa people (: Now I have to fix the KMS stuff too :)
*** Bug 18342 has been marked as a duplicate of this bug. ***
Confirmed. That last patch from you on a pristine 2.5.1 as included in ubuntu jaunty fixes the bug!!! (does not need the lvdshack 'if (!on)' workaround anymore). Great work Jesse, thank you very much for your persistence! My excuses about the late response. About the other issues I mentioned earlier, they may simply be something just for my install, because there is something with how ubuntu/debian package the libdrm headers that don't make sense to me (https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/308387), and I needed to edit libdrm includes from the ubuntu packages to get the driver to compile, plus I really don't know how any details how libdrm, the drm.ko kernel module and this driver interact, so I could very well have done something wrong there. I can imagine there are many ways how there could be some sort of api mismatch in there somewhere...
Oops, I noticed one problem with the last patch. Everything works properly, BUT the brightness of the display is set to its maximum every time the Xorg is restarted. For instance, when I boot up, I always set my brightness to value 6 (ranging from 0 to 8 in this laptop) in /sys/class/backlight/acpi_video0/brightness. However, after booting, when Xorg starts, the Intel driver sets the brightness to the maximum (8). Again, if during Xorg I change the brightness, and then restart the Xorg, the brightness is set back to the maximum. Could you please check this issue? Thank you in advance.
Another thing (by the way), I am trying to compile 2.5.99.2 in Debian (I fetched the sources from experimental), but I have a versioning problem with libdrm (I think Jelle had similar problems in Ubuntu). ./configure tells me that libdrm required must be >= 2.4.3, but 2.4.1 was found. However, in my system, I have libdrm-2.4.3, so I don't understand where is the catch: claudio@silver:~$ dpkg -l | grep drm | awk '{print $2" "$3}' libdrm-dev 2.4.3+git+20090105+a8c5480-1 libdrm-intel1 2.4.3+git+20090105+a8c5480-1 libdrm2 2.4.3+git+20090105+a8c5480-1 Jelle, do you have a clue? How can I tamper with things in /usr/include in order to get it built??
(In reply to comment #191) > Another thing (by the way), > > I am trying to compile 2.5.99.2 in Debian (I fetched the sources from > experimental), but I have a versioning problem with libdrm (I think Jelle had > similar problems in Ubuntu). > > ./configure tells me that libdrm required must be >= 2.4.3, but 2.4.1 was > found. I actually don't know how the Debian repository could possibly build 2.5.99.2 automatically if their latest libdrm-dev package is 2.4.3 but it shows 2.4.1, the repository build should give the same error I got. I am really confused now.
Claudio, My LCD brightness is also at max level, however I can't change it. I had been using keyboard shortcuts for the 'Guidance Power Manager' (via the kde 'System Settings'), but they have no effect with the latest driver+kernel. My /sys/class/backlight/sys/class/backlight has no files or subdirectories in it... I don't know why that is. I think the xserver-xorg-video-intel package in Debian and Ubuntu is probably built against the 2.6.27 kernel package, and has not been rebuilt since the introduction of 2.6.28, because there has been no trigger for it to need to happen (no new xserver-xorg-video-intel update, and no other dependency trigger has occured). This is how I understand those packages are made in Debian and Ubuntu: Parts of the libdrm include files are added to the linux kernel source package. When that is built, besides the kernel and kernel headers, one of the .deb's you get is 'linux-libc-dev', which is the one that includes the libdrm include files. The libdrm-dev package does not supply the libdrm include files on a debian/ubuntu install. So, when you build xserver-xorg-video-intel, the libdrm includes from linux-libc-dev need to be compatible with the libdrm that xserver-xorg-video-intel is expecting. Even though xserver-xorg-video-intel has build-dependencies on libdrm-dev and libdrm-intel1, those dependencies are not complete because the libdrm include files are not available in the libdrm-dev debian package. There is no version numbering link of any kind between libdrm and linux-libc-dev, so afaics it is not possible to specify the correct dependency in the xserver-xorg-video-intel package. So. in debian and ubuntu, the libdrm include files are supplied by the linux-libc-dev package, which is part of the kernel source package... They end up there through manual patching by the people involved with making those packages. What I think is that the linux-libc-dev from 2.6.27 probably _does_ have libdrm include files that allow xserver-xorg-video-intel to be built (but I did not verify that), and since there is no dependency link, the xserver-xorg-video-intel package will not break until the package is rebuilt by its maintainer after switching to 2.6.28... I don't know why they do it like that, but that is how (it looks to me) they do it. It doesn't look like the right way to me, but it's quite possible that I simply don't know enough about the intricacies of everything involved on that subject... Anyway, I built the xserver-xorg-video-intel that I'm using right now with linux-libc-dev (and kernel) package version 2.6.28-4.10 and the 2.4.1 version of the various libdrm packages, plus manually adding the missing struct to the one include file that I mention in the ubuntu bug ticket (that I mentioned in my previous posting). The only package that I built myself is the xserver-xorg-video-intel package, the rest are all the latest ubuntu jaunty official packages. But, of course, the fact that it built and somewhat works (crashes after resume, and sometimes shows the wrong window content (both only if compositing is on)), that does not mean that I did it completely right... I don't know if the drm.ko, and/or libdrm library from the ubuntu packages and/or my hand-edited libdrm includes are correct for the xserver-xorg-video-intel that I built. afaics, that is because of how the libdrm includes are currently handled, it is not possible to have complete dependencies and build dependencies for the xserver-xorg-video-intel package (I had all dependencies satisfied but it still didn't build because of the linux-libc-dev and libdrm include-file intermixing...). I just know it compiled and somewhat works... I hope the libdrm-dev and linux-kernel package maintainers of debian and ubuntu get this straightened out. Claudio, I hope this answers your questions.
> ./configure tells me that libdrm required must be >= 2.4.3, but 2.4.1 was > found. AFAIK configure picks up the version from /usr/lib/pkgconfig/libdrm.pc which is shipped by libdrm-dev. Maybe you have something laying around from older custom builds. The libdrm-dev package you mention contains correctly 2.4.3.
BTW, I am building intel (trunk) packages on top of 2.6.28 in the Launchpad "personal package archive" https://launchpad.net/~xorg-edgers/+archive (the Jaunty packages). The source packages should also build fine on Debian (modulo needed kernel headers).
(In reply to comment #193) > Claudio, > > My LCD brightness is also at max level, however I can't change it. I had been > using keyboard shortcuts for the 'Guidance Power Manager' (via the kde 'System > Settings'), but they have no effect with the latest driver+kernel. My > /sys/class/backlight/sys/class/backlight has no files or subdirectories in > it... I don't know why that is. The file /sys/class/backlight gets created with the following kernel options: CONFIG_ACPI_SYSFS_POWER CONFIG_ACPI_VIDEO CONFIG_BACKLIGHT_LCD_SUPPORT CONFIG_LCD_CLASS_DEVICE CONFIG_LCD_PLATFORM CONFIG_BACKLIGHT_GENERIC After that, you should be able to write a number between 0 and 8 into /sys/class/backlight/acpi_video0/brightness. With older kernels than 2.6.28, you can use /sys/class/sony-laptop/backlight/brightness (AFAIR), but ACPI does all the work already with those options I told you. The problem with the Intel driver (at least on 2.5.1) is that it resets the brightness value to 8 (maximum) every time the Xorg is (re)started. About the explanations, thank you, you really took the time to explain everything in detail. Anyway, I don't know which version of Intel driver are you building, I was trying to build 2.5.99.2, because 2.5.1 builds without problem. However, about the Debian versioning, I think that probably Debian people built against 2.6.26 headers. But then, I am confused again, since intel-2.6.0 needs certain definitions that are only in 2.6.29, which are not provided in the linux-libc-dev-2.6.26 (Debian). I, nevertheless, manually installed the linux-libc-dev-2.6.28 from Ubuntu but still I get problems. I guess I have to wait a little bit more still, not everything can be fixed at once. Thank you Jelle for being so focused on the thing :)
> --- Comment #196 from Claudio Camacho <claudiomkd@gmail.com> 2009-01-15 01:21:19 PST --- > However, about the Debian versioning, I think that probably Debian people built > against 2.6.26 headers. But then, I am confused again, since intel-2.6.0 needs > certain definitions that are only in 2.6.29, which are not provided in the > linux-libc-dev-2.6.26 (Debian). I, nevertheless, manually installed the > linux-libc-dev-2.6.28 from Ubuntu but still I get problems. > ubuntu gets the drm headers from the kernel. debian still uses those from libdrm for now, so there's no need to update the kernel headers.
Hi Jesse, For what is worth, the brightness is totally respected now with 2.6.0. So, using your last patch about h&vblank after h&vsync, this bug is closed. I checked the brightness issue that I reported early but it is all gone with xf86-intel-2.6.0. Thank you for everything, and I hope you can let us know if this patch is going to be included in 2.6.1 or, if not, in which one.
(In reply to comment #198) > Hi Jesse, > > For what is worth, the brightness is totally respected now with 2.6.0. So, > using your last patch about h&vblank after h&vsync, this bug is closed. > > I checked the brightness issue that I reported early but it is all gone with > xf86-intel-2.6.0. > > Thank you for everything, and I hope you can let us know if this patch is going > to be included in 2.6.1 or, if not, in which one. Thanks for testing. Yeah I'm hoping my fix will make it into 2.6.1. I haven't received a satisfactory answer from the Windows guys on how they deal with this, which makes me a little worried, but we can certainly add the workaround anyway and fix it up later if/when they get back to me with something useful. I'll close this bug with a reference to the commit once I push it.
Created attachment 22255 [details] [review] check VBT timing sanity at BIOS init time I'd appreciate if someone could test this patch for me as it's the one I'd like to push upstream for 2.6.2. Thanks.
Hi Jesse, Good news! This last patch works. Actually, because I didn't know if I had to test using the previous patch also, I tested in both ways: once using only this last patch, and another test with both patches. I have to say that both work similarly. If you let me (I am an ignorant), I think that using only the last patch that you just uploaded, the screen goes off and then on when switching from VT to X. With both patches applied, the screen never goes off at all, but just blank, between VT and X switch. This is, obviously, with KMS disabled, since there would be not mode change and, besides, you know that KMS still doesn't work for me. To sum up, the patch works. So please, put it into the 2.6.2, I would like to use the Intel driver without recompiling every time ^_^ Thank you very much for everything :-)
Thanks for confirming, Claudio, and everyone for all your testing and effort in this bug. Fix pushed as commit 57a02b50c60c10a25ff0f3cd93af9f37fa0d1b11 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Jan 26 14:58:28 2009 -0800 Fixup bogus VBT modes when detected
I have just upgraded to the latest version available on git (your latest patch was already included). Feedback about the driver : Good: - LVDS display is working perfectly fine (including suspend and so on) - Slightly better performance (compared to 2.4.1) Bad: - Black screen occurs again when an external VGA monitor is connected - System freeze when a VGA screen is plugged or unplugged while X running Linux arwen 2.6.28-5-generic #15-Ubuntu SMP Thu Jan 22 21:21:04 UTC 2009 i686 GNU/Linux if you need any other info that i could provide, feel free to ask here !
(In reply to comment #203) I had no chance to test this newest patch, but in response to Aurélien: > - System freeze when a VGA screen is plugged or unplugged while X running Actually, that also happens when using the VESA-driver. It also happens when the X-server is not even loaded. At least on my Sony VAIO VGN SR19XN. I have this problem since I bought it. Only workaround for me: Quick jump into standby; attatch the monitor; wake up. So I don't think, the intel-devs can change anything on this behavior. That must be some general fuck-up from Sony. Seems like they use to do this kind of stuff when it comes to linux-compatibility. I'll test the patch asap. Thanks in advance!
Ah no! /me kills the zombie bug returning from the dead Please file a separate bug for the VGA hotplug issue. Sounds like Sony tries to do something smart at VGA hotplug time. There may be a way to disable it on your platform (try the ACPI DOS settings in /proc/acpi), but really it's a separate issue from the mode timing bug here.
(In reply to comment #205) > Ah no! /me kills the zombie bug returning from the dead > > Please file a separate bug for the VGA hotplug issue. Sounds like Sony tries > to do something smart at VGA hotplug time. There may be a way to disable it on > your platform (try the ACPI DOS settings in /proc/acpi), but really it's a > separate issue from the mode timing bug here. > i understand about the vga "hotplug" thing, but the "can't connect my laptop to a vga monitor" is really related to this patch
Are you sure? There's also a VGA plane patch that's been causing trouble for some people (db9f5915ce812144ffd9d2aa42e8ba856129c35e in case you want to try reverting). Anyway, please file a separate bug describing the symptoms and include the logs, etc. Thanks.
Created attachment 22279 [details] Xorg.log with BO depth buffer error Alright. I just installed the latest git-commit. But there was this one thing I forgot. I can't use 2.5.0+ in general. xorg.log says: >>(EE) intel(0): Failed to pin depth buffer: Cannot allocate memory >>Fatal server error: >>Couldn't bind memory for BO depth buffer I just attached the whole Xorg.log I know - it's not related to this bugreport. That's just my way to say: I would like to test the patch but I can't ;-).
(In reply to comment #208) > Created an attachment (id=22279) [details] > Xorg.log with BO depth buffer error > > Alright. > I just installed the latest git-commit. > But there was this one thing I forgot. > I can't use 2.5.0+ in general. > > xorg.log says: > >>(EE) intel(0): Failed to pin depth buffer: Cannot allocate memory > >>Fatal server error: > >>Couldn't bind memory for BO depth buffer Do you already have a bug open for this problem? If not, please file one and attach the log (kernel log too, but make them text/plain this time :).
Jesse, fwiw after putting the patch into Intrepid to get some testing for you, one regression did show up, where the display gets scrambled on an i915: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/320893 He reports """ The difference I see in the xorg logs is this, when broken: (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x1024 - internal error instead of this, when working: (EE) intel(0): Mode 1280x1024 does not fit virtual size 1024x768 - internal error """ I can file a new bug on this if it'd be preferred.
I should add, the above was with the patch in comment #182 rather than from #200, if that matters.
While I'm adding myself to the CC list I should mention that there are at least three people reporting the regression Bryce linked to. Should be enough for testing.
Can you file a new bug for it and close this one again? Also can you try the more recent patch (the one I pushed into xf86-video-intel)? And make double sure it's just this single patch that causes the new regression, as opposed to something else in the update.
Well done Jesse. I'm using the 2.6.0, with your latest patch. I'm using it with xorg 7.3, and libdrm 2.4.4 and kernel 2.6.29-rc3-git3 but I don't know why it does not work with kms, any assumption ?
I still need to apply the same patch to the KMS code; until then it'll fail like the old 2D driver. :)
(In reply to comment #215) > I still need to apply the same patch to the KMS code; until then it'll fail > like the old 2D driver. :) > Could you plesae inform us when you include the patch in the kernel, I can't wait to test KMS on my GM45 (:
Here's the equivalent KMS patch, pushing now. diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios index 4ca82a0..f42e2ff 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -111,6 +111,12 @@ parse_panel_data(struct drm_i915_private *dev_priv, struct panel_fixed_mode->clock = dvo_timing->clock * 10; panel_fixed_mode->type = DRM_MODE_TYPE_PREFERRED; + /* Some VBTs have bogus h/vtotal values */ + if (panel_fixed_mode->hsync_end > panel_fixed_mode->htotal) + panel_fixed_mode->htotal = panel_fixed_mode->hsync_end + 1; + if (panel_fixed_mode->vsync_end > panel_fixed_mode->vtotal) + panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end + 1; + drm_mode_set_name(panel_fixed_mode); dev_priv->vbt_mode = panel_fixed_mode;
That's nice :) Hoping it goes into -rc4 and I can test it on my machine. Thank you, Jesse, for all the good work you are doing (:
fwiw, ubuntu jaunty now has 2.6.1, but it doesn't have the "Some VBTs have bogus h/vtotal values" patch to i830_bios.c from comment #200. I got the broken display again until I added it and recompiled.
Great work man; I got kms worked with intel 2.6.1 and kernel 2.6.29-rc7 but i got a strange debug message: glxgears do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly. Try adjusting the vblank_mode configuration parameter. what does it mean?
Don't reopen an old bug just because new issue. See comment#181.
I just tested a live CD of openSUSE Factory w/ 2.6.3 and it still leaves me with a blank screen (Sony Vaio VGN-FW190). The only difference being the screen is black, not grey! I'll leave the bug as closed, but is this an issue with the patch?
(In reply to comment #222) > I just tested a live CD of openSUSE Factory w/ 2.6.3 and it still leaves me > with a blank screen (Sony Vaio VGN-FW190). The only difference being the screen > is black, not grey! I'll leave the bug as closed, but is this an issue with the > patch? > I am running a Sony VAIO VGN-FW140E/H laptop. While running Mandriva 2009 PWP I consistently got a grey screen, not a black one. I used VESA for several months as a workaround. Strangly, it allowed me a slightly accelerated video. GoogleEarth and Stellarium were jumpy, but usable. I was waiting for the fix to trickle down to Mandriva when I noticed that Kunbuntu 9.04 was featuring KDE 4.2, so I decided to give the LiveCD a try. Imagine my surprise when it gave me a fully functional 3D accelerated video. Stellarium give 67 fps and GoogleEarth is as smooth as silk! It uses the 2.6.28-11-generic kernel and i915 video driver. The video chip is: 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
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.