|Summary:||[915G SDVO-LVDS] Not able to start X|
|Product:||xorg||Reporter:||Guek Wu Neo <neogw>|
|Component:||Driver/intel||Assignee:||Wang Zhenyu <zhenyu.z.wang>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||medium||CC:||antoni, chiangqy, eich, kent.liu, libv, mat, michael.fu, quanxian.wang, sndirsch|
|i915 platform:||i915 features:|
Description Guek Wu Neo 2008-11-12 00:33:15 UTC
Created attachment 20239 [details] Xorg.0.log Intel Corporation 82915G/GV/910GL Integrated Graphics Controller [8086:2582] (rev 0e) Problem description: Not able to startX. Problem exist is Sles11 beta1/2/ 3/4 Error message:Not able to start X with error message " maximum number of X display failures reached. We need to fix the issue and use the Intel driver. VESA is not an option.
Comment 3 Gordon Jin 2008-11-12 18:10:46 UTC
"maximum number of X display failures reached" is the same as bug#18462, though Xorg log error is different. Does older intel driver ever work on this machine?
Comment 4 Wang Zhenyu 2008-11-12 18:16:03 UTC
Looks like another SDVO LVDS bug report. What's your machine? Please provide us info so we might seek to buy one and work on this. 'hwinfo' is mostly unreadable, any program needed to interpret it?
Comment 5 Guek Wu Neo 2008-11-12 18:57:19 UTC
this is video card is used in IBM Point of Sales(POS) terminal. Attached hwinfo is from POS model 4846-565. you can open the atatched 'hwinfo' using text editor eg vi editor in linux or wordpad in windows. This video card works on 'i810' driver in SLES10 as in bug#18462.
Comment 6 Wang Zhenyu 2008-11-12 19:43:01 UTC
yeah, as we don't have support for SDVO LVDS modesetting in current video driver, you have to use i810 or vesa which base on video bios to set mode for you, which is also noted at http://developer.novell.com/yes/91036.htm For adding support for it, we need hardware first...
Comment 7 Guek Wu Neo 2008-11-13 03:18:06 UTC
Stefan mentioned i810 driver not available for X.Org 7.4 per bug#18462. i tried i810 is also does not working.
Comment 8 Stefan Dirsch 2008-11-22 02:19:59 UTC
Guek, does at least vesa driver work on this machine?
Comment 9 Guek Wu Neo 2008-11-23 18:43:30 UTC
yes this work with vesa
Comment 10 Eric Anholt 2008-11-24 18:24:33 UTC
Would it be possible to get a sample of your hardware to test on? We haven't encountered hardware like this before, as people using lvds typically build a mobile chip in.
Comment 11 Michael Fu 2008-11-24 18:30:29 UTC
basically our decision is overall we will keep SDVO-LVDS as unsupported because the request is really low. Unless we can get something as Eric mentioned in comment# 10. Or, if using vesa is fine in your situation and you won't bother to find a sample, we can mark this bug as wontfix anyway.
Comment 12 Guek Wu Neo 2008-11-24 19:08:11 UTC
The terminal has an LCD interface chip Chrontel CH7308. With this, does it complicate the intel driver support?
Comment 13 Michael Fu 2008-11-24 19:25:41 UTC
(In reply to comment #12) > The terminal has an LCD interface chip Chrontel CH7308. With this, does it > complicate the intel driver support? > yes, this is the SDVO LVDS device we mean... usually platform will use integrated LVDS , that's why SDVO LVDS request is low in our list - in fact, this is the only bug we received. We can't find the card or a platform with SDVO LVDS from the market, either. So, that's why I suggest if vesa is good enough for your solution, you can stay with that.
Comment 14 Michael Fu 2008-11-25 21:07:34 UTC
*** This bug has been marked as a duplicate of bug 11645 ***
Comment 15 Guek Wu Neo 2008-11-26 06:59:40 UTC
Created attachment 20611 [details] Xorg.0.log after installing the NLPOS9 SSP3 IEGD rpm package In NLPOS9 SSP3 there is a the IEGD video driver to support this video card. http://downloadcenter.intel.com/Detail_Desc.aspx?ProductID=2159&DwnldID=13823&lang=eng We have tried the package in SLED11 Beta 5, but is not succesfull. attached is the Xorg.0.log. Could we have one similar package to work in SLES11/SLED11?
Comment 16 Antonio Quizon 2008-12-14 21:58:00 UTC
Hello michael, Have you received the machines, any updates for this bug?
Comment 17 Michael Fu 2008-12-14 22:02:53 UTC
(In reply to comment #16) > Hello michael, > > Have you received the machines, any updates for this bug? > No, I havn't yet.
Comment 18 Antonio Quizon 2009-01-09 06:52:43 UTC
Michael, Any updates on your ivestigation? appreciate your response.
Comment 19 Wang Zhenyu 2009-01-11 17:07:13 UTC
We have tested recent driver on ibm machine here, which works fine. You can try current git master or 18.104.22.168 release. It's fixed by commit 59b0fbb9be880d489374b141f818948a2721a2ef Author: Henry unbongo <email@example.com> Date: Mon Dec 29 13:54:38 2008 -0800 Add support for SDVO LVDS.
Comment 20 Stefan Dirsch 2009-01-11 23:54:33 UTC
Comment 21 Chiang Qiyu 2009-01-12 23:07:27 UTC
Created attachment 21920 [details] Photos of problem display Hi, I tested out the rpm in comment #20 on SLED 11 RC 1 and there are display problems with the intel driver. I've attached a rar containing 2 photos of the display. Also, PS/2 and USB keyboards lock up after I log in. The mouse pointer functions normally, but there is no response to mouse clicks.
Comment 22 Chiang Qiyu 2009-01-12 23:08:32 UTC
Created attachment 21921 [details] Xorg log with intel driver
Comment 23 Chiang Qiyu 2009-01-12 23:10:10 UTC
Created attachment 21922 [details] xorg config file used
Comment 24 Wang Zhenyu 2009-01-14 21:29:13 UTC
Remove all "800x600" lines in your xorg.conf. Current SDVO LVDS can only drive native panel mode, no scaling is supported now.
Comment 25 Guek Wu Neo 2009-01-15 01:24:37 UTC
Hi ZhenYu, What do you mean by "Current SDVO LVDS can only drive native panel mode, no scaling is supported now" ? this terminal comes with an integrated 1024x768 resolution panel. do you mean that we can only have 1024x768 in the xorg.cong instead of 800x600? had done a experiment. found that if we use the intel driver and run sax2 to chnage the resolution to 1024x768, the integrated 1024x768 resolution panel now works in proper with correct resolutiion.
Comment 26 Chiang Qiyu 2009-01-15 05:13:19 UTC
Thanks Zhenyu. Commenting out the "800x600" lines fixed the display issue. The machine now displays properly. sax2 is also able to detect the native monitor resolution (1024x768) with the intel driver. It wasn't able to do so with the vesa driver. The keyboard lock issue I mentioned in comment #21 seems to be due related to the screen depth. At 16 depth, the system locks after user login. When I set it to 24 depth, the OS is able to load properly after user logon. This happens even at 1024x768 resolution. Is this a limitation (i.e. only 1024x768 @ 24 bit colour is supported), or some sort of driver issue?
Comment 27 Chiang Qiyu 2009-01-15 05:16:15 UTC
Created attachment 22008 [details] xorg.conf This xorg.conf works if I make only 1 change - setting the default depth to 24. At depth 16, the keyboard locks after user logon.
Comment 28 Chiang Qiyu 2009-01-15 05:17:27 UTC
Created attachment 22009 [details] Xorg log This is the xorg log if I use the xorg.conf in comment #27
Comment 29 Kent Liu 2009-01-15 18:35:25 UTC
(In reply to comment #27) > This xorg.conf works if I make only 1 change - setting the default depth to 24. > > At depth 16, the keyboard locks after user logon. Are you use SLED11 RC1 to do test?? We observed some strange appearance in snapshots before RC1 when setting to 16-bit color depth, but disappeared in RC1. Maybe you can have a try...
Comment 30 Chiang Qiyu 2009-01-15 19:19:14 UTC
Yes, I'm currently testing on SLED 11 RC 1. There is no display problem at 1024x768 @ 16bit depth. The issue is that the keyboard locks and the OS stops loading after I do a user logon. If I change the default depth of the xorg.conf (attached in comment #27) to 24bit, there is no keyboard issue and the OS continues loading.
Comment 31 Michael Fu 2009-01-15 20:12:22 UTC
(In reply to comment #30) > Yes, I'm currently testing on SLED 11 RC 1. There is no display problem at > 1024x768 @ 16bit depth. The issue is that the keyboard locks and the OS stops > loading after I do a user logon. > > If I change the default depth of the xorg.conf (attached in comment #27) to > 24bit, there is no keyboard issue and the OS continues loading. > why not just use 24bit, if your platforms support? I'm not sure if this is a driver issue or not, but we've put 16bit depth support low priority and basically won't bother with it anymore. Can I mark this bug as fixed then, if the display issue has been resolved?
Comment 32 Michael Fu 2009-01-15 23:08:01 UTC
(In reply to comment #30) > Yes, I'm currently testing on SLED 11 RC 1. There is no display problem at > 1024x768 @ 16bit depth. The issue is that the keyboard locks and the OS stops > loading after I do a user logon. > > If I change the default depth of the xorg.conf (attached in comment #27) to > 24bit, there is no keyboard issue and the OS continues loading. > Chiang Qiyu, I also suggest you to just get rid of the xorg.conf and let the system decide itself and see what will happen... thanks.
Comment 33 qwang13 2009-01-16 03:18:03 UTC
Given a suggestion for SLE11-RC1 when you test graphics. sax2 tools will set the graphics configuration automatically and accurately. When you think xorg.conf is not right. Just run this tools, it will generate the xorg.conf more accurate. sax or sax2 is useful to test graphics in SLED environment. I am not sure if it can make you comfortable. Just give a try, maybe there is a surprise.
Comment 34 Chiang Qiyu 2009-01-19 02:31:06 UTC
(In reply to comment #31) > > why not just use 24bit, if your platforms support? I'm not sure if this is a > driver issue or not, but we've put 16bit depth support low priority and > basically won't bother with it anymore. > I was just curious as to why the system locks with 16bit as we might have to document it as some sort of limitation. Thanks for the clarification. > > Can I mark this bug as fixed then, if the display issue has been resolved? > We're currently still testing to see if it works with dual displays. (In reply to comment #33) > > sax2 tools will set the graphics configuration automatically and accurately. > > When you think xorg.conf is not right. Just run this tools, it will generate > the xorg.conf more accurate. > As mentioned earlier, sax2 seems to run fine with the intel driver. Thanks for the suggestion.
Comment 35 Wang Zhenyu 2009-01-19 19:30:33 UTC
I think this bug should be closed now?
Comment 36 Guek Wu Neo 2009-01-20 02:22:00 UTC
there seems to be something weird that on the terminal is sensitive to this line 'DefaultColorDepth16bit' in the xorg.conf. We were testing out the terminal together with 2 video cards. Pri is the mentioned "Intel Corporation 82915G/GV/910GL" and the secondary card is the ATI ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] [1002:5159]. some how when we tried to 'DefaultColorDepth16bit' in the secondary screen, the primary integrated display will start up ok in the login screen but after login, it gets to a total white screen in Xdesktop. It will display OK on both pri and secondary screen if there is no 'DefaultColorDepth16bit' under the Section Screen of both Pri and secondary display. Pls help to investigate and feedback.
Comment 37 Guek Wu Neo 2009-01-20 02:28:35 UTC
Created attachment 22111 [details] Xorg.0.log when use defaultColorDepth 16 in section screen
Comment 38 Guek Wu Neo 2009-01-20 02:45:52 UTC
the white screen mentioned in comment #36 is only of the integrated monitor that is driven by intel chip. while the external monitor attached to the secondary ATI card is displaying ok.
Comment 39 Stefan Dirsch 2009-01-20 03:16:10 UTC
Looks like you're using 16bit for radeon and 24bit for intel driver. Why? Also I'm afraid that mulitcard setups are utterly broken with newer X.Org releases like 1.5.
Comment 40 Wang Zhenyu 2009-01-20 22:23:02 UTC
Guek, please open new bug for your new problem, we'd stick one problem one bug, and this bug is fixed.
Comment 41 Michael Fu 2009-01-20 22:44:03 UTC
(In reply to comment #36) > there seems to be something weird that on the terminal is sensitive to this > line 'DefaultColorDepth16bit' in the xorg.conf. > > We were testing out the terminal together with 2 video cards. > Pri is the mentioned "Intel Corporation 82915G/GV/910GL" and the secondary > card is the ATI ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] > [1002:5159]. > > some how when we tried to 'DefaultColorDepth16bit' in the secondary screen, the > primary integrated display will start up ok in the login screen but after > login, it gets to a total white screen in Xdesktop. > > It will display OK on both pri and secondary screen if there is no > 'DefaultColorDepth16bit' under the Section Screen of both Pri and secondary > display. > > Pls help to investigate and feedback. > Stefan is right. we will only try to resolve intel-only card configuration bugs.. thanks.
Comment 42 Guek Wu Neo 2009-01-22 00:05:33 UTC
i am afraid this is linked to intel chipset. This is because even for single display setup, per earlier feedback in comment#30. We encounter terminal hang after logging into Xdesktop if there is 16bit dept setup in the xorg.conf. could you help to do more investigation?
Comment 43 Stefan Dirsch 2009-01-22 01:09:19 UTC
Guek, could you explain why you want to use 16bit?
Comment 44 Guek Wu Neo 2009-01-22 01:20:06 UTC
we are using an external monitor that run on 16bit color depth. this external monitor is supposed to be driven by the radeon card. Do not know why this setup is affecting the integrated display instead which supposed to be driven by the intel card that we already know in comment#30 is sensitive to 16bitcolor depth. thus we need to know if it is a constraint to use 16bitcolor depth here? If is this need to be make known to user.
Comment 45 Stefan Dirsch 2009-01-22 01:32:14 UTC
16bit monitor sounds weird to me. I would assume that using it with 24bit works as well. Still I'm afraid that multicard setups like radeon/intel in newer X.Org releases simply do not work, no matter in which color depth. Mixing color depths makes it even harder, if not impossible.
Comment 46 Guek Wu Neo 2009-01-22 01:45:34 UTC
i already posted the multiple cards encounter problem for this machine under novell bugzilla #468159. I am posting this 16bitcolor depth encounter here to let Intel know as well as i am not sure if is related to intel driver as well.
Comment 47 Guek Wu Neo 2009-01-22 02:02:49 UTC
Stefan, The 16bit color depth for the integrated monitor is setup default by SAX on fresh installation. I had justed installed SLESRC2, is configured as DefaultDepth16.
Comment 48 Stefan Dirsch 2009-01-22 02:33:39 UTC
We use Defauldepth 16 for ATI Radeon ES1000 onboard graphics, but not for i915. How can one expect that a vendor combines two onboard graphic chips, so a strange mixture is the default, when one creates a multicard setup? Why don't you at least try to use 24bit also for this Radeon chip? Maybe it does works. But there must have been a reason why we use 16bit as default for it.
Comment 49 Guek Wu Neo 2009-01-28 03:28:28 UTC
Sax2 -p shows Chip: 0 is -> IBM 915 G 00:02:0 0x8086 0x2582 PCI vesa Chip: 1 is -> ATI Radeon VE 01:12:0 0x1002 0x5159 AGP radeon single display: Device is tie to BusID 00:02:0 in the xorg.conf. If defaultDepth is 16, StartX login screen OK, But hang at XDestop. If defaultDepth is 24, Display XDesktop ok. Dual Display: Device is tie to BusID 00:02:0 in the xorg.conf. (Intel915) Device is tie to BusID 01:12:0 in the xorg.conf. (ATI Radeon) If used DefaultDepth16 on Device, DefaultDepth24 on Device==> see black screen on both monitor If used DefaultDepth24 on Device, DefaultDepth16 on Device==> see black screen on both monitor If i used DefaultDepth24 for both cards, Both screen will display OK provided xinerama and clone is turn off. If i used DefaultDepth24 for both cards, Both screen will not be ok when either xinerama and clone is turn on. Stefan, Thus Is there way that you can configure sax to set DefaultDepth24 for this machine? Then we continue to work on the dual display in novell bugzilla #468159
Comment 50 Stefan Dirsch 2009-01-28 06:51:51 UTC
We use 16bit as default for vesa driver. For intel and radeon driver it's 24bit. For Radeon ES1000 it's 16bit. As mentioned earlier you can't create Multicard setups with SaX2 any more. And why are we now discussing issues here releated to vesa driver ?!?
Comment 51 Guek Wu Neo 2009-01-29 01:55:01 UTC
Stefan, Thank you for highlighting that it will be DefaultDepth16 for vesa driver. With this, we can consider this intel bug fixed. Do help to pick up this intel driver patch for Novell next RC release. Will proceed to respective Novell bugzilla to request to tune to use intel driver for this card. Thank you Thank you Intel team.
Comment 52 Stefan Dirsch 2009-01-29 02:16:30 UTC
The patch is already on SLE11-RC3.