MXM Video Card that has been unsolvable for over 8 years - Page 1
Forum section: electronics / general

author: itelite
author_rank: Contributor
timestamp: January 18, 2017, 02:26:12 am
content: Seeking assistance with an issue regarding a GPU upgrade on the HP HDX9000I am experiencing an issue with screen brightness as explained below.A swap from the stock GT8800M to a Quadro FX2700m or FX3700m has been the goal of this project for years.I was able to come in and figure out the physical connections to make it happen, but we are stuck with one persistent issue.I am experienced engineer and have dug far deeper than anyone ever should into this problem and have listed my results below.Looking for someone to help solve this last little issue.Stock GPU MXM Card = Nvidia 8800mReplacement GPU MCM Card = Nvidia Quadro FX2700 or FX3700Pinout between cards is identical except for the LVDS channels being reversed. That is to say the ODD and EVEN LVDS channels are exactly a mirror of each other.Pinout issue is resolved by flipping pin order on cable.On this model Vbios is loaded from a module in the SBIOS. This is resolved via Vbios injection.With these 2 changes made the card works nearly perfectly. Performance is great, fully recognized by Windows and Ubuntu.The issue is the screen brightness. It is very low, and is not adjustable via keyboard keys or in OS.Brightness issue is apparent from post and in all operating systems. This leads me to believe it is not driver or OS related.Now here is where it gets strange.If i inject one of several different VBIOS rather than the FX2700m or FX3700m i get correct brightness and working brightness control. This includes the stock 8880M vbios, as well as 8800m Vbios from IBM, and Dell. (totally wrong cards, the dell not even being an MXM card)Although the brightness works, just about everything else does not. In most cases it will crash within a few minutes.This result is expected, but leads me to conclude the brightness issue is not a physical or electrical issue at all, but rather some element of the FX2700 or FX3700m VBIOSThis led me to believe it was a PWM signal issue. I fed an external PWM signal into the CCFL inverter and could control the brightness by varying the PWM signal. In this case with the FX2700m or FX3700m Vbios in use externally controlled maximum duty cycle resulted in the low brightness. It could be brought lower, but never higher. This is confirmed by measuring the frequency and duty cycle of the internal machine provided PWM signal. It is running at full brightness.With the other Vbios (8800m) this exact same PWM signal results in an appropriately bright screen.In addition, i took the CCFL inverter out of the equation, and used a fully external, and externally powered CCFL inverter. Results in a dim display with FX Vbios, and Bright Display with 8800m VBIOS.This leads me to conclude it is not an issue related to the CCFL inverter, or CCFL inverter control (PWM).I modified the EDID on the LCD screen itself to adjust GAMMA values, White Balance Values and a others. Although the image changed, nothing effected the brightness issue.any thoughts?I have not yet experimented with hardware straps, but am considering that as the next course of action.I firmly believe something is being asserted in the Quadro Vbios that is being unintentionally brought high or low and causing this behavior.

author: itelite
author_rank: Contributor
timestamp: January 18, 2017, 02:37:13 am
content: Quote from: blueskull on January 18, 2017, 02:33:14 amOh how I wish it was that easy.With PWM high it is indeed as bright as it goes, but with the Quadro card it is no where near as bright as with the Stock card. This is true in the cases of tieing PWM high (tried with both 3.3v and 5v just for the hell of it), Using an arduino to control PWM frequency, as well as using a signal generator to control PWM signal.This is a truly vexing one for me

author: amyk
author_rank: Super Contributor
timestamp: January 18, 2017, 04:21:19 am
content: I suspect it could be the difference between the BIOS configuring for 6bpp and 8bpp panels, thus LVDS signal is missing high 2 bits of each pixel and maximum intensity is 1/4 of what it should be. You could use one of the various LCD monitor test charts available to see if e.g. you see every 4 pixel values mapping to the same intensity, which could confirm this hypothesis.Useful reference:http://www.intel.com/design/intarch/papers/315975.pdf

author: itelite
author_rank: Contributor
timestamp: January 18, 2017, 02:30:32 pm
content: Quote from: amyk on January 18, 2017, 04:21:19 amI will look into this. I will say this, all of the pixels are being utilized. So the card is understanding what is on the other end of it, at least in that regard. Though i must admit, the intensity of the pixels is not something i have checked into at all yet in this painful journey

author: itelite
author_rank: Contributor
timestamp: January 18, 2017, 02:57:06 pm
content: Adding the data sheets for the LCDs, if anything jumps out to anyone.

author: itelite
author_rank: Contributor
timestamp: January 18, 2017, 07:58:39 pm
content: Quote from: itelite on January 18, 2017, 02:30:32 pmWould you mind elaborating on this a bit. I read through the document provided, but i did not see anything about pixel intensity, or which bits would control such a thing.Thank You

author: amyk
author_rank: Super Contributor
timestamp: January 19, 2017, 03:20:44 am
content: Quote from: itelite on January 18, 2017, 02:57:06 pmThat was easy... the LG is a 6bpp panel and the Chimei a 8bpp panel. Do you see that one is 256K colours while the other is 16M? One has only 3 LVDS lanes whereas the other has 4? Page 14 of the Chimei datasheet shows that the high 2 bits are in the 4th lane, so if the GPU is configured for 6bpp, then it doesn't use that channel and instead scales down by 4; a 8bpp panel takes intensities from 0 to 255 (11111111), a 6bpp panel only uses 0 to 63 (111111). If the GPU is configured for 6bpp then the 8bpp panel will only ever see intensities 0 to 63 instead of 0 to 255, meaning everything is 1/4 as bright as it should be.The document I linked compares 18bpp and 24bpp (different terminology for 6bpp and 8bpp) panels and shows that some 8bpp panels ("24.0") instead shift thelowesttwo bits into the 4th lane, while others ("24.1", the Chimei) put the highest two bits there. A 24.0 would work in your configuration, as a 6bpp panel, whereas the 24.1 shows the symptoms you're experiencing.

author: itelite
author_rank: Contributor
timestamp: January 19, 2017, 03:28:27 pm
content: Quote from: amyk on January 19, 2017, 03:20:44 amOk, excellent. This is all lining up web to what i am experiencing.Next question. Do you have any idea what changes need to be made in the Vbios to change from 6bpp to 8bpp?As i mentioned the first post, when i use the original(wrong for card) bios with the new card, with the original LCD, the brightness works as expected. So presumably the capability is there, it is just operating in 6bpp mode. Which makes sense given the environment it was pulled from.I will be researching this myself, but if it is a few bytes and a checksum somewhere that would be swell.

author: itelite
author_rank: Contributor
timestamp: January 19, 2017, 03:32:13 pm
content: Adding Nvidia DCB 4.0 Spec

author: amyk
author_rank: Super Contributor
timestamp: January 20, 2017, 03:15:22 am
content: Quote from: itelite on January 19, 2017, 03:28:27 pmIf you can find a VBIOS for that GPU which is present in a computer with an 8bpp panel but otherwise identical or very close configuration, maybe you could diff them to figure out which bits are different. I doubt it will require changing more than a byte or two, but unfortunately there is little public documentation...

author: itelite
author_rank: Contributor
timestamp: February 22, 2017, 01:32:06 am
content: An Update:I obtained a HP Elitebook 8730w. This is the machine the MXM video card came out of. It had 6bpp lcd in it. I put in a 8bpp lcd to test this theory. It displays correctly without any modification whatsoever. Not noticeably brighter though. Certainly not 4x brighter. So it would seem the card equally happy to display to either screen.This leads me to suspect the 8bpp vs 6bpp is not the real problem in this case.Anyone have any other thoughts?

author: amyk
author_rank: Super Contributor
timestamp: February 22, 2017, 04:20:14 am
content: Quote from: itelite on February 22, 2017, 01:32:06 amI quoted above in the document, that LCDs vary in which bits of which lanes they expect the intensity information, so it is certainly possible that an 8bpp LCD will work fine (but with only 6bpp effective resolution) if it was expecting the least significant bits of intensity on the extra lane.

author: itelite
author_rank: Contributor
timestamp: February 22, 2017, 02:35:45 pm
content: Is there a way to definitively determine/measure the effective bpp actually in use in either case?

author: RGB255_0_0
author_rank: Frequent Contributor
timestamp: February 22, 2017, 03:09:57 pm
content: Quote from: itelite on February 22, 2017, 02:35:45 pmhttp://www.lagom.nl/lcd-test/gradient.php

author: itelite
author_rank: Contributor
timestamp: February 22, 2017, 03:41:37 pm
content: Ok, i just took a look at the gradient test. On the 8bpp lcd there is noticeable banding and small movements in the image when you look close.i viewed the same image on a nice IPS desktop monitor and it is smooth. So there is a difference for sure.So i suppose this means the 8bpp lcd is being run at 6bpp, possibly with dithering?i guess we are back to the card is using 6bpp regardless of the LCD on the end.Another member messaged me for dumps of the Vbios chips which i will be sending shortly. If such a thing would be any value to anyone i will gladly share them publicly.