LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   Intel Sandy Bridge graphics -- running lines on screen (https://www.linuxquestions.org/questions/linux-hardware-18/intel-sandy-bridge-graphics-running-lines-on-screen-942450/)

klurik 04-29-2012 05:29 PM

Intel Sandy Bridge graphics -- running lines on screen
 
Several months ago I have purchased a HP 3420 (Free DOS) monoblock with intel integrated graphical adapter Sandy Bridge. That was risky but I was too happy that it have not preinstalled MS OS. Installation went fine, got common problem with non-free wifi, etc.
After installation completion and first reboot the screen turns black. All sounds are producing and I can "in blind" turn off pc.

I tried several distros and left with Debian 6 (2.6 kernel) and vesa driver.
Further playing (with modprobe, xrandr, xorg,.. can't recall now) yields a configuration Debian 6(3.2 kernel from bpo), i915 kernel module and ugly running lines on the screen.
I worked on this PC with vesa drivers in low resolution believing that newer kernel could fix it.

On a gentoo forum (will find link on demand) I've seen the recommendation of monolitical build of i915 with kernel.
Today I've managed to build such a kernel (3.3.4) but lines are not gone :(
(well, my video camera is gone, but never mind)

lspci output:
Code:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5)
00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H61 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
02:00.0 Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5116 PCI Express Card Reader (rev 01)

dmesg | grep intel
Code:

intel_idle: MWAIT substates: 0x1120
intel_idle: v0.4 model 0x2A
intel_idle: lapic_timer_reliable_states 0xffffffff
agpgart-intel 0000:00:00.0: Intel Sandybridge Chipset
agpgart-intel 0000:00:00.0: detected gtt size: 2097152K total, 262144K mappable
agpgart-intel 0000:00:00.0: detected 65536K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xc0000000
fbcon: inteldrmfb (fb0) is primary device
fb0: inteldrmfb frame buffer device
snd_hda_intel 0000:00:1b.0: irq 47 for MSI/MSI-X

xrandr
Code:

Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
eDP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 440mm x 250mm
  1600x900      58.0 +
  1440x900      59.9*
  1360x768      61.5    59.8    60.0 
  1152x864      60.0 
  1024x768      60.0 
  800x600        60.3    56.2 
  640x480        59.9 
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)

With vesa drivers everything is OK, but low screen resolution makes me nervous, please help :)

cascade9 05-01-2012 04:39 AM

Squeeze is older than the 'sandy bridge' video chip, so the standard xorg and mesa versions dont support it very well.

I'd try backporting xserver-xorg-core, xserver-xorg-video-intel, and mesa (maybe xserver-xorg-video-vesa as well).

klurik 05-01-2012 08:21 AM

Thank you for reply,

I just tried to reinstall (aptitude -t squeeze-backports reinstall xserver-xorg-video-intel, etc) packages you mentioned, and installed a number of packages containing mesa in their names (libegl1-mesa, libglu1-mesa, libgl1-mesa-glx, ibegl1-mesa-drivers). Unfortunately this does not cure the problem.

As for old Squeeze, most of other distributives I tried from LXF live-CD, yields the black screen (smth wrong with framebuffer as I heard). As well as Debian Testing (tried in ~January).

The only succeed distro was TinyCore 4.3, which gave me the correct screen resolution.
It uses something named Xvesa, think, I'll dig in that direction.

cascade9 05-02-2012 04:26 AM

You did try chaning back to mesa, right?

Xvesa is very simple, and its possible its ignoring what is causing the problem with vesa/mesa.

Since you are ghavign resolution problems, maybe your system EDID isnt being reported correctly. That would explian the resolution problems, and the lines as well.

klurik 05-05-2012 02:35 PM

Quote:

Originally Posted by cascade9 (Post 4668319)
You did try chaning back to mesa, right?

Sorry, I'm not sure what did you mean here... Does mesa interfere with vesa/intel drivers? I though it is OpenGL support libraries or so.

Quote:

Originally Posted by cascade9 (Post 4668319)
Xvesa is very simple, and its possible its ignoring what is causing the problem with vesa/mesa.

Yes, probably. But I failed to find any easy ways to use Xvesa in Debian installation. Doubt that I'l ever install Tiny Core, other Xvesa distros gave be blank (black) screen.

Quote:

Originally Posted by cascade9 (Post 4668319)
Since you are having resolution problems, maybe your system EDID isnt being reported correctly. That would explian the resolution problems, and the lines as well.

Well, get-edid | parse-edid gives some numbers, not sure reliable they or not

Code:

get-edid: get-edid version 2.0.0

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0
        Function supported
        Call successful

        VBE version 300
        VBE string at 0x11100 "Intel(R) Sandybridge/Ivybridge Graphics Chipset Accelerated VGA BIOS"

VBE/DDC service about to be called
        Report DDC capabilities

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0
parse-edid: parse-edid version 2.0.0
        Function supported
        Call successful

        Monitor and video card combination does not support DDC1 transfers
        Monitor and video card combination supports DDC2 transfers
        0 seconds per 128 byte EDID block transfer
        Screen is not blanked during DDC transfer

Reading next EDID block

VBE/DDC service about to be called
        Read EDID

        Performing real mode VBE call
        Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0
        Function supported
        Call successful

parse-edid: EDID checksum passed.

        # EDID version 1 revision 3
Section "Monitor"
        # Block type: 2:0 3:fc
        Identifier "HP Omni / Pro"
        VendorName "HWP"
        ModelName "HP Omni / Pro"
        # Block type: 2:0 3:fc
        # DPMS capabilities: Active off:no  Suspend:no  Standby:no

        Mode        "1600x900"        # vfreq 60.000Hz, hfreq 60.000kHz
                DotClock        108.000000
                HTimings        1600 1780 1860 1800
                VTimings        900 910 913 1000
                Flags        "-HSync" "-VSync"
        EndMode
        Mode        "1440x900"        # vfreq 64.939Hz, hfreq 64.939kHz
                DotClock        106.500000
                HTimings        1440 1620 1700 1640
                VTimings        900 910 913 1000
                Flags        "+HSync" "+VSync"
        EndMode
        Mode        "1360x768"        # vfreq 63.143Hz, hfreq 54.808kHz
                DotClock        85.500000
                HTimings        1360 1540 1600 1560
                VTimings        768 778 781 868
                Flags        "+HSync" "+VSync"
        EndMode
        # Block type: 2:0 3:fc
EndSection

I could guess resolutions for screen mode (like gtf 1360 768 58) and set them with xrandr, so that lines are less blinking. But the result is far from desired.

There is no way to get wide screen resolution with vesa, and no simple way to install xvesa, am I right?

(Added: seems that +hsync +vsync keys are only significant)

Thanks for attention

business_kid 05-06-2012 01:13 PM

Lines on screen I take to be many near horizontal lines, which is because the horizontal sync is too fast. The xorg.conf.d needs something for the video with the words

HorizSync 31.5-60
VertRefresh 50-90

Find your monitor's specs and enter them. Change to console runlevel usually 3, in /etc/inittab so you can get feedback and use startx to start X. If you can't find your monitor specs, try those. Keep slowing the HorizSync by 5 (31.5-55) until the picture stands up.

If it's thick black lines rolling up and down, slow VertRefresh ;-).

klurik 05-07-2012 09:55 AM

Quote:

Quote:
Originally Posted by cascade9 View Post
You did try chaning back to mesa, right?
Sorry, I'm not sure what did you mean here... Does mesa interfere with vesa/intel drivers?
Ahh, yes, mesa could use software drivers, removed that mesa-dri package for clarity..


Quote:

Originally Posted by business_kid (Post 4671758)
Lines on screen I take to be many near horizontal lines, which is because the horizontal sync is too fast. The xorg.conf.d needs something for the video with the words

HorizSync 31.5-60
VertRefresh 50-90

Find your monitor's specs and enter them. Change to console runlevel usually 3, in /etc/inittab so you can get feedback and use startx to start X. If you can't find your monitor specs, try those. Keep slowing the HorizSync by 5 (31.5-55) until the picture stands up.

If it's thick black lines rolling up and down, slow VertRefresh ;-).

Yes, you telepathied right, lines are horizontal :)
Thank you! This is a good clue.

With vesa drivers xvidtune reported

hsync range 0: 31.50 - 48.00
vsync range 0: 50.00 - 70.00

and most of the EDID provided modes exceed the number 48.

Short search says it could happen of stereo modes..
In Xorg.0.log contains a bunch of such lines:

[ 17.752] (II) intel(0): DDCModeFromDetailedTiming: Ignoring: We don't handle stereo.

I think it is a big step forward :)

I have stopped gdm3, so that X is not active, and made xorg.conf with monitor frequencies range, and started X again, following business_kid's recipe.

As a result the lines are become less in numbers and a lot shorter, but not gone entirely.
The same effect is achieved with xrandr and +hsync +vsync.

The insertion of generated by http://xtiming.sourceforge.net/cgi-bin/xtiming.pl modelines in xorg.conf gave no progress yet. May be this tool is way too old?

I'l keep combine modes, move to Debian Testing, or, most probably, come back to work :)

Thank you for your help )

business_kid 05-07-2012 01:46 PM

48khz is very slow. You're back to interlaced modes (if they work) or 800x600.

The limiting factor _should_be_ the monitor. Have you a decent monitor?

You could set HorizSync to 31.5-48, & VertRefresh to 50-70 and take out all the modes, and you should get a picture; let it figure out what it can do.

I suspect what's going on is that the video card is slowing down things. If you have a slow monitor, X can handle that. I think you have a slow redraw; So the monitor says it can do 60khz, so X sets up for 60khz, and sets the appropriate dot clock but the video card can't keep up and you get horizontal lines. It's a driver problem or a crap monitor.

klurik 05-08-2012 05:03 PM

Quote:

Originally Posted by business_kid (Post 4672664)
48khz is very slow. You're back to interlaced modes (if they work) or 800x600.

The limiting factor _should_be_ the monitor. Have you a decent monitor?

Yes.
This monitor is binded with all other stuff (All-in-One PC), so it should be good enough.

Quote:

You could set HorizSync to 31.5-48, & VertRefresh to 50-70 and take out all the modes, and you should get a picture; let it figure out what it can do.
It dropped the 1900x600 and used 1360x768 (xrandr --verbose):
Code:

        1360x768 (0x44)  84.8MHz -HSync +VSync *current
        h: width  1360 start 1432 end 1568 total 1776 skew    0 clock  47.7KHz
        v: height  768 start  771 end  781 total  798          clock  59.8Hz

and short running line strips, like I had with +hsync :/

There is no hsync, so, you may be right :)

Quote:

I suspect what's going on is that the video card is slowing down things. If you have a slow monitor, X can handle that. I think you have a slow redraw; So the monitor says it can do 60khz, so X sets up for 60khz, and sets the appropriate dot clock but the video card can't keep up and you get horizontal lines. It's a driver problem or a crap monitor.
Hope, it is driver problem, changing the monitor is impossible, and there is no video-out to check with another device

business_kid 05-09-2012 04:04 AM

My nose is good on this stuff - I came from a tv background. You're stuck with what you've got, then, but the monitor is good.
Quote:

Hope, it is driver problem, changing the monitor is impossible, and there is no video-out to check with another device
Are we running a vesa drivers here? if so, better stick with 4:3 modes, despite the fact that you have a 16:9 monitor. (=800x600) If not, we can be brave.

Give xorg.conf.d the video section of an xorg.conf. Give it
HorizSync 31-5-48
VertRefersh 50-70
Virtual 800 464

Give it every conceivable option for the driver, commented out so you can try them and they might grab you some extra speed.Hit a mode calculator and work out an 800x464 mode.

And in the Display section under 24 bit give it the mode "800x464" and , and run startx >somefile 2>&1.

I did this (no modeline)with a new (to the system)video card and it was very funny. I gave it 1440x900 as a mode. X read the file, and said "Hmmph! Mode "1440x900" is clearly ridiculous - deleting it". Then followed a session where it tried to decide what mode to use, terminating in

"All right then, ask the @%$! thing what it can do. . .
It says it can do 1440x900. Let's try and roll one of those."
And a picture appeared :-).

If this is happening on your box, it's screwing you up. The monitor will announce very optimistic specs, X will roll an optimistic mode, and you are screwed.

klurik 05-24-2012 04:00 PM

Thank you for your help,

Quote:

Originally Posted by business_kid (Post 4674064)
Are we running a vesa drivers here? if so, better stick with 4:3 modes, despite the fact that you have a 16:9 monitor. (=800x600) If not, we can be brave.

With vesa drivers I had good picture, but recently glx support was broken (/dev/fb0 disappeared). I blame my experiments with tiny X core etc.
So, with vesa (nomodeset) I have now clear picture, no 3D, no tty :(

With intel driver (i915) I still got no clear picture.. It is hard for me to explain effect so I uploaded this video: http://youtu.be/L64to6WJFGM

Quote:

"All right then, ask the @%$! thing what it can do. . .
It says it can do 1440x900. Let's try and roll one of those."
And a picture appeared :-).
I'm pretty sure I've seen this previously.. Results are not better then on video.


I found some guys managed to get good image with gallium driver (?) on Ubuntu.
I asked them for detailed timings, and got this:
Code:

1600x900 (0x138) 110.9MHz *current
h: width 1600 start 0 end 0 total 1600 skew 0 clock 69.3KHz
v: height 900 start 0 end 0 total 900 clock 77.0Hz

Will think what can I do with this data.

business_kid 05-25-2012 03:43 AM

The only thing I've seen remotely like the startup crap was 'sound on video' which could occur in some tvs. It's apparently getting the horizontal right early on but having difficulty with the vertical setting.

Then I think you're running in 640x480 or some such with a much larger virtual screen. If you move your mouse against the edges (go to the left and keep going left, that sort of thing) does the picture move about?

klurik 05-25-2012 10:33 AM

Quote:

Originally Posted by business_kid (Post 4687140)
The only thing I've seen remotely like the startup crap was 'sound on video' which could occur in some tvs. It's apparently getting the horizontal right early on but having difficulty with the vertical setting.

Thats probably virtualbox whines about something.. But works Ok.

Quote:

Then I think you're running in 640x480 or some such with a much larger virtual screen. If you move your mouse against the edges (go to the left and keep going left, that sort of thing) does the picture move about?
No. It does not move. I see normal picture, the last few seconds on that video are zoomed print-screen.

Quote:

Give xorg.conf.d the video section of an xorg.conf. Give it
HorizSync 31-5-48
VertRefersh 50-70
Virtual 800 464
Should I try with 800x464 modes? Strange numbers, thats not a typo?

Is there any requirements for files in xorg.conf.d? Or I can put here anything with .conf ending?

business_kid 05-27-2012 03:56 AM

800x464 is basically ok. The hassle is with the horizontal, vertical can be nearly anything. It tells me that the thing is not able to go fast for some reason. Possible causes are
low throughput (likely)
low settings on monitor(HorizSync) or dot clock(video).

Lousy driver. I'd use that for a bit and gather strength and ideas.

klurik 06-04-2012 06:49 AM

I blame framebuffer!
 
The problem is not in the intel-xorg drivers, not in mesa glx libs..

The wide lines appeared at the early stage of kernel load. so it is Framebuffer and KMS.

The next effort is to get rid of KMS.

I succeed here with grub2 settings, bit still no valid 3d support :(
(May be I'l open separate brunch of nomodeset 3d support)

Added to /etc/default/grub:
Code:

GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"
GRUB_GFXMODE=1600x900
GRUB_GFXPAYLOAD_LINUX=1600x900

update-grub

and /etc/modprobe.d/i915-kms.conf is changed:
Code:

options i915 modeset=0


Thank you for your help :)


All times are GMT -5. The time now is 11:40 AM.