LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware
User Name
Password
Linux - Hardware This forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?

Notices


Reply
  Search this Thread
Old 04-29-2012, 05:29 PM   #1
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Rep: Reputation: 1
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

Last edited by colucix; 04-30-2012 at 12:45 AM. Reason: Fixed.
 
Old 05-01-2012, 04:39 AM   #2
cascade9
Senior Member
 
Registered: Mar 2011
Location: Brisneyland
Distribution: Debian, aptosid
Posts: 3,753

Rep: Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935
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).
 
Old 05-01-2012, 08:21 AM   #3
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
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.
 
Old 05-02-2012, 04:26 AM   #4
cascade9
Senior Member
 
Registered: Mar 2011
Location: Brisneyland
Distribution: Debian, aptosid
Posts: 3,753

Rep: Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935Reputation: 935
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.
 
1 members found this post helpful.
Old 05-05-2012, 02:35 PM   #5
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
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? I though it is OpenGL support libraries or so.

Quote:
Originally Posted by cascade9 View Post
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 View Post
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

Last edited by klurik; 05-05-2012 at 03:18 PM. Reason: Add sync
 
Old 05-06-2012, 01:13 PM   #6
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,086

Rep: Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753
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 ;-).
 
1 members found this post helpful.
Old 05-07-2012, 09:55 AM   #7
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
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 View Post
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 )
 
Old 05-07-2012, 01:46 PM   #8
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,086

Rep: Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753
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.
 
Old 05-08-2012, 05:03 PM   #9
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
Thumbs up

Quote:
Originally Posted by business_kid View Post
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
 
Old 05-09-2012, 04:04 AM   #10
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,086

Rep: Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753
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.
 
Old 05-24-2012, 04:00 PM   #11
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
Thank you for your help,

Quote:
Originally Posted by business_kid View Post
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.
 
Old 05-25-2012, 03:43 AM   #12
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,086

Rep: Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753
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?
 
Old 05-25-2012, 10:33 AM   #13
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
Quote:
Originally Posted by business_kid View Post
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?
 
Old 05-27-2012, 03:56 AM   #14
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, RPi OS, Mint & Android
Posts: 13,086

Rep: Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753Reputation: 1753
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.
 
Old 06-04-2012, 06:49 AM   #15
klurik
LQ Newbie
 
Registered: Feb 2012
Location: Russia
Distribution: Debian 6
Posts: 15

Original Poster
Rep: Reputation: 1
Smile 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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: OpenIndiana With Intel Sandy Bridge? LXer Syndicated Linux News 0 10-08-2011 08:03 PM
LXer: The Rough Story Of Intel Sandy Bridge Graphics For Mac OS X LXer Syndicated Linux News 0 07-25-2011 05:31 AM
Sandy Bridge graphics on Scientific Linux 6.1 allanw Red Hat 0 07-24-2011 10:49 PM
LXer: Intel's Linux Sandy Bridge Graphics Still Troubling LXer Syndicated Linux News 0 01-18-2011 02:50 PM
LXer: Intel Sandy Bridge Linux Graphics? It's A Challenge LXer Syndicated Linux News 0 01-03-2011 12:40 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Hardware

All times are GMT -5. The time now is 10:01 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration