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.
Created attachment 20240 [details] xorg.conf
Created attachment 20241 [details] hwinfo
"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?
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?
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.
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...
Stefan mentioned i810 driver not available for X.Org 7.4 per bug#18462. i tried i810 is also does not working.
Guek, does at least vesa driver work on this machine?
yes this work with vesa
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.
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.
The terminal has an LCD interface chip Chrontel CH7308. With this, does it complicate the intel driver support?
(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.
*** This bug has been marked as a duplicate of bug 11645 ***
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?
Hello michael, Have you received the machines, any updates for this bug?
(In reply to comment #16) > Hello michael, > > Have you received the machines, any updates for this bug? > No, I havn't yet.
Michael, Any updates on your ivestigation? appreciate your response.
We have tested recent driver on ibm machine here, which works fine. You can try current git master or 2.5.99.2 release. It's fixed by commit 59b0fbb9be880d489374b141f818948a2721a2ef Author: Henry unbongo <henryunbongo@yahoo.com> Date: Mon Dec 29 13:54:38 2008 -0800 Add support for SDVO LVDS.
Guek, package for testing: http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.1/i586/xorg-x11-driver-video-7.4-41.1.i586.rpm
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.
Created attachment 21921 [details] Xorg log with intel driver
Created attachment 21922 [details] xorg config file used
Remove all "800x600" lines in your xorg.conf. Current SDVO LVDS can only drive native panel mode, no scaling is supported now.
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.
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?
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.
Created attachment 22009 [details] Xorg log This is the xorg log if I use the xorg.conf in comment #27
(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...
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.
(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?
(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.
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.
(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.
I think this bug should be closed now?
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.
Created attachment 22111 [details] Xorg.0.log when use defaultColorDepth 16 in section screen
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.
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.
Guek, please open new bug for your new problem, we'd stick one problem one bug, and this bug is fixed.
(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.
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?
Guek, could you explain why you want to use 16bit?
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.
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.
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.
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.
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.
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[0] 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[0] is tie to BusID 00:02:0 in the xorg.conf. (Intel915) Device[1] is tie to BusID 01:12:0 in the xorg.conf. (ATI Radeon) If used DefaultDepth16 on Device[0], DefaultDepth24 on Device[1]==> see black screen on both monitor If used DefaultDepth24 on Device[0], DefaultDepth16 on Device[1]==> 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
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 ?!?
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.
The patch is already on SLE11-RC3.
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.