[i830] [Needs DVO-LVDS] Installer unable to launch Xorg on Fujitsu Stylistic ST4120PW

[chrome]

I'm unable to install Jaunty on Fujitsu Stylistic ST4120PW tabletpc computer. It has Intel 830M graphics controller. When I try to install from a cd, it prepares to launch X, after starting it blinks screen a few times, and finally I get black screen with vertical white stripes growing for a few seconds and finally filling whole screen. The system underneath doesn't crash. I can switch to text console and it works, and then when returning to X just the same white stripes appear. Sometimes, but not always, when switching console from text mode to X I can see X desktop for a split second just after the switch, but it instantly disappears and the stripes start to fade black to white. Oh, and stripes are not exactly the same every time, sometimes there are more stripes, and sometimes less.

Exactly the same happens when trying to install in safe mode.

I tried switching drivers manually by editing xorg.conf, and this is what happens when trying to start X after edits (the xorg.conf file is all default, with just 'Driver ...' line added):

1) Driver "intel"
result:
(EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
(EE) intel(0): tfp410 not detected got VID 1305: from VOI2C_E Slave 112.
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

Above messages appear about 2 seconds after running 'X' and show after a split-second black screen.

2) Driver 'i810'
result:
(EE) No devices detected.

This time the messages appear after about 1 second and a split-second black screen. I don't know if this driver is supposes to support 830M or not, I just gave it a try.

3) And finally: Driver 'vesa'
result:
After running 'X' it shows black screen for about 10 seconds, then it turns off the backlight for about 2 seconds, and then it turns on the backlight again and start the black to white stripes fading. Switching to the text console from which I started X shows some logs, but they are related to XKEYBOARD, so I don't consider them important.

In Xorg.0.log I can find lines about different modules loading. Some maybe interesting lines are:
(II) VESA(0): Not using built-in mode "640x480" (no mode of this name)
...
(WW) VESA(0): No valid modes left. Trying less strict filter
...
(**) VESA(0): Using "Shadow Framebuffer"
...

I'll try to attach the whole file.

I have also tried installing 8.10 and the results are exactly the same. If I'll find earlier versions' discs I'll try them too.

[H Pastoriza (hpastoriza)]

Created an attachment (id=19368)
xorg.conf

[H Pastoriza (hpastoriza)]

Created an attachment (id=19370)
output of intel_reg_dumper running the 1.7.4 version of the driver

[Jesse Barnes (jbarnes-virtuousgeek)]

Can you attach your video rom?

# cd /sys/devices/pci0000\:00/0000\:00\:02.0/
# echo 1 > rom
# cat rom > /tmp/rom.bin
# echo 0 > rom

[H Pastoriza (hpastoriza)]

Created an attachment (id=19436)
Video ROM

Here it is.

[Tlinden-cc (tlinden-cc)]

I have exactly the same problem that the intel driver for a 830M fails to start with the error messages
(EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
(EE) intel(0): tfp410 not detected got VID 1305: from DVOI2C_E Slave 112.
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

System environment:
-- chipset: Intel Corporation 82830
-- system architecture: 32-bit
-- xf86-video-intel: 2.5.0-3 (from Fedora 10)
-- xserver: X.Org X Server 1.5.2
-- kernel: 2.6.27.5-41.fc9.i686
-- Linux distribution: Fedora 9
-- Machine or mobo model: Fujitsu Siemens S6010 Lifebook laptop
-- Display connector: Internal TFT-display

Additional info: The S6010 laptop has an internal 1024*768 TFT display and there is also the normal external VGA connector.

The BIOS has the following settings:
  Video Features / Display
    Internal Flat Display
    External
    Simultaneous
At the moment I use the setting "nternal Flat Display".

I have used RedHat 7.3, Fedora Core 3, 4, 5 and 6 and Fedora 7, 8 and 9 on this
S6010 laptop. Only the old i810 driver has worked and I have never been able to start the new intel driver.

I created a minimal xorg.conf with
  system-config-display --set-driver=intel --reconfig
and added
  Option "ModeDebug" "yes"

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20555)
xorg.conf with Option "ModeDebug" "yes"

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20556)
Xorg.0.log with only the internal TFT display attached

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20557)
Xorg.0.log using both the internal TFT and an external 1600x1200 VGA display

[Tlinden-cc (tlinden-cc)]

Attaching an external 1600x1200 monitor to the VGA port results in that startx hangs instead of ending with error messages as in the previous case. While startx was hanging I run
  intel_reg_dumper
see the next attachement.

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20558)
Output of intel_reg_dumper using internal TFT and external VGA displays.

[Tlinden-cc (tlinden-cc)]

lspci -v for the display chipset:

00:02.0 VGA compatible controller: Intel Corporation 82830 CGC [Chipset Graphics Controller] (rev 04) (prog-if 00 [VGA controller])
        Subsystem: Fujitsu Limited. Unknown device 113c
        Flags: bus master, fast devsel, latency 0, IRQ 11
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Memory at e0080000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 1
        Kernel modules: i915, intelfb

00:02.1 Display controller: Intel Corporation 82830 CGC [Chipset Graphics Controller]
        Subsystem: Fujitsu Limited. Unknown device 113c
        Flags: bus master, fast devsel, latency 0
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at e0100000 (32-bit, non-prefetchable) [size=512K]
        Capabilities: [d0] Power Management version 1
        Kernel modules: i915

[Tlinden-cc (tlinden-cc)]

The video rom output obtained with:
  cd /sys/devices/pci0000\:00/0000\:00\:02.0/
  echo 1 > rom
  cat rom > /tmp/rom.bin
  echo 0 > rom
is shown in the next attachement.

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20559)
The video ROM of the graphics chipset.

[Tlinden-cc (tlinden-cc)]

This seems to be the same as bug 11148 which has been marked as a duplicate of bug 13722.

[Tlinden-cc (tlinden-cc)]

I have been using the framebuffer driver fbdev on my S6010 since the intel driver replaced the old i810 driver in Fedora.
The next attachment is the output of
  intel_reg_dumper
when I use the fbdev driver and only the internal TFT screen with the BIOS setting
  Video Features / Display
    Internal Flat Display

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20570)
output of intel_reg_dumper with only internal TFT display and framebuffer driver

[Tlinden-cc (tlinden-cc)]

To be able to drive a projector I need to use the BIOS setting
  Video Features / Display
    Simultaneous
when using the frambuffer driver. The next attachment is the output of
this situation with both the internal TFT and external VGA display in
use.

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20571)
output of intel_reg_dumper with framebuffer driving internal TFT and external VGA

[Jesse Barnes (jbarnes-virtuousgeek)]

Thanks for attaching your video BIOSes. Unfortunately the info I was looking for isn't as easy to find as I had hoped. My guess is that on these platforms the DVO attached LVDS encoder is at an address not expected by the i830_dvo.c code. You could try playing with the addrs or disassembling your ROMs to see what ends up getting poked.

Based on Tomas' logs, it looks like there's something at i2c slave addr 112, but apparently not a TI TFP410 (since it returns 1305 for a read of addresses 0 and 1). So it could be that your encoder is at the TFP410 address but is a different device that we don't handle yet...

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=20686)
Xorg.0.log for the S6010 with the old i810 driver running Knoppix 5.1.1

[Tlinden-cc (tlinden-cc)]

I attached in the previous post the Xorg.0.log from the old i810 driver which worked fine. Hopefully that could give some clue about what goes wrong with the new intel driver.

I have tried to use also the vesa and vga drivers on Fedora 9 and they both fail to start, so the the only driver that works at the moment is the fbdev. Does each driver detect the hardware independently?

[Ciaran-gillespie (ciaran-gillespie)]

I have the exact same problem with my Fujitsu Stylistic ST4110, and the "intel" driver. It worked fine with the "i810" driver, but openSUSE 11.1 no longer has it as an option.

It too uses the i830M "82830 CGC" Intel chip set, and gives an "X fails to start as no valid screens are found."

Unless an external monitor is connected, then the external monitor displays a running X session, but the internal flat panel shows white vertical stripes that get progressively brighter.

I'd love for this bug to be fixed.

[Tlinden-cc (tlinden-cc)]

I booted my S6010 laptop with a Fedora 11 beta Live CD. If I have an external monitor connected to the laptop, then only the external monitor shows any picture. Without the external monitor I get no picture at all.
With this setup the error messages
  (EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
  (EE) intel(0): tfp410 not detected got VID 1305: from DVOI2C_E Slave 112.
are gone. There are these warnings given
  (WW) Falling back to old probe method for vesa
  (WW) Falling back to old probe method for fbdev
  (WW) intel(0): Disabling Xv because no adaptors could be initialized.
I also set in the BIOS that I want to have simultaneously the internal and external displays. I still have not been able to find any way of getting the output on the laptops TFT screen.

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=24677)
Xorg.0.log with external display attached and using a Fedora 11 beta Live CD

[Tlinden-cc (tlinden-cc)]

The intel driver does not give any output on the laptop screen or only a grey slowly changing pattern that probably is because the display is being driven by a too high refresh rate, which might potentially be dangerous for the display. I changed the severity of the bug therefore from enhancement to major.

[chrome (chrome.x86)]

I'm unable to install Jaunty on Fujitsu Stylistic ST4120PW tabletpc computer. It has Intel 830M graphics controller. When I try to install from a cd, it prepares to launch X, after starting it blinks screen a few times, and finally I get black screen with vertical white stripes growing for a few seconds and finally filling whole screen. The system underneath doesn't crash. I can switch to text console and it works, and then when returning to X just the same white stripes appear. Sometimes, but not always, when switching console from text mode to X I can see X desktop for a split second just after the switch, but it instantly disappears and the stripes start to fade black to white. Oh, and stripes are not exactly the same every time, sometimes there are more stripes, and sometimes less.

Exactly the same happens when trying to install in safe mode.

I tried switching drivers manually by editing xorg.conf, and this is what happens when trying to start X after edits (the xorg.conf file is all default, with just 'Driver ...' line added):

1) Driver "intel"
result:
(EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
(EE) intel(0): tfp410 not detected got VID 1305: from VOI2C_E Slave 112.
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.

Above messages appear about 2 seconds after running 'X' and show after a split-second black screen.

2) Driver 'i810'
result:
(EE) No devices detected.

This time the messages appear after about 1 second and a split-second black screen. I don't know if this driver is supposes to support 830M or not, I just gave it a try.

3) And finally: Driver 'vesa'
result:
After running 'X' it shows black screen for about 10 seconds, then it turns off the backlight for about 2 seconds, and then it turns on the backlight again and start the black to white stripes fading. Switching to the text console from which I started X shows some logs, but they are related to XKEYBOARD, so I don't consider them important.

In Xorg.0.log I can find lines about different modules loading. Some maybe interesting lines are:
(II) VESA(0): Not using built-in mode "640x480" (no mode of this name)
...
(WW) VESA(0): No valid modes left. Trying less strict filter
...
(**) VESA(0): Using "Shadow Framebuffer"
...

I'll try to attach the whole file.

I have also tried installing 8.10 and the results are exactly the same. If I'll find earlier versions' discs I'll try them too.

[chrome (chrome.x86)]

Xorg.0.log after running xorg.conf set with Driver "vesa":

(Final Backtrace happens after I kill the server with ctrl-alt-backspace or with ctrl+c on text terminal, everything before happens after starting the server)

[chrome (chrome.x86)]

Xorg.0.log after running xorg.conf set with Driver "intel":

[chrome (chrome.x86)]

Xorg.0.log after running X with xorg.conf set with Driver "i810"

[Jesse Barnes (jbarnes-virtuousgeek)]

Sorry, still an enhancement. This feature has never been supported by driver code (prior to 2.0 it was done in the VBIOS). Someone needs to write support for this DVO chip. If you can figure out which DVO chip your machine has, the docs are often available, so you could get it going yourself (the drivers are usually pretty simple).

[Jesse Barnes (jbarnes-virtuousgeek)]

Oh and I don't think I'll be doing this. I don't have any test hardware for it.

[aaardwark (aaardwark)]

I've got a Fujitsu Siemens Lifebook S6010. It has the same graphics card, the same problem, and the same error message.

This problem started with the "intel" driver in gutsy I believe. Since then I've had to specify driver "i810" i xorg.conf. However since Ubuntu 8.10 driver "810" is no longer available, making it kind of hard to upgrade.

One thing that could be relevant is that the "intel" driver works, as long as another display is connected to the computer. It is only the laptop display that encounter these problems. So I've figured the problem has something to do with how the "intel" driver a while back changed it's way of detecting screens, which doesn't work very well with the Intel 830M graphics controller.

Tell me if there is anything I can do to help. This bug has been around to long (and ruined my xmas holidays, before realising older Ubuntu works, different screen works, and i810 driver works). Which logs do you need? Is there anything you want me to test?

[aaardwark (aaardwark)]

Here's some general info from trying the Xubuntu live-cd:

xserver-xorg-video-intel:
  Installed: 2:2.6.3-0ubuntu9
  Candidate: 2:2.6.3-0ubuntu9
  Version table:
 *** 2:2.6.3-0ubuntu9 0
        500 http://archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

Description: Ubuntu 9.04
Release: 9.04

Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

[aaardwark (aaardwark)]

...And here's my output of lspci -vvnn

[aaardwark (aaardwark)]

I believe we have a bunch of duplicates with the same problem. I'm not going to mark them as such since I believe there are people better suited to to make that judgement. But here is a list:
Bug #257711
Bug #272560
Bug #238105

I'd also like to ad I tried the vesa driver, and had the exact same result as above.

No idea how many people are affected by this. But I know of no workaround for intrepid or jaunty (except always having an external screen connected to the laptop). In hardy, the latest LTS, you have to ad driver "i810" to xorg.conf. You have to install Ubuntu with alternate install or an external screen before doing so. All this I think is more than the average user can handle. That makes this bug extremely critical to a small audience.

[smk666 (mt-vanquisher)]

Have the same problem, can't even install ubuntu.
Specs:
Fujitsu Stylistic ST4121
Intel830 gfx
Pentium III 933Mhz
512MB ram
Tried 8.10, 9.04 and 9.04 netbook remix with the same result

[chrome (chrome.x86)]

smk666 pisze:
> Have the same problem, can't even install ubuntu.
> Specs:
> Fujitsu Stylistic ST4121
> Intel830 gfx
> Pentium III 933Mhz
> 512MB ram
> Tried 8.10, 9.04 and 9.04 netbook remix with the same result
>
>

As a workaround, you can install 8.04 from 'alternate installer'
(text-based installer) - downloadable from ubuntu site. This is the last
version supporting old 'i810' driver, which works fine on 41xx Stylistics.

Also, you can install 7.04 (and perhaps some olders) in the normal way -
this is the last version which works from normal cd with graphical
installer.

Best regards, Kuba

[smk666 (mt-vanquisher)]

I tried 7.04 and it works well, but I have some new problems.
1. Moving windows, scrolling windows and video playback from youtube etc. are very choppy
2. I can't login without external keyboard
3. Hardware buttons doesn't work
4. Pen input do not rotate together with the desktop
5. WiFi can connect only to unsecured networks

I guess I will have to rollback to XP Tablet :(

[aaardwark (aaardwark)]

I got a mail with a reasonable explanation of the problem, that I'd like to ad to the report:

"My investigations on the net indicate that the source of the problem is
the LVDS (built-in LCD panel) controller of the graphics card. In my
case this is a National 2501 chip. It seems that older drivers (i810)
have supported it, but the new ones (intel) does not. I don't know why.
In some older readmes there are some references to the code supporting
this chip, for example here:
(http://downloadmirror.intel.com/df-support/9871/ENG/RELNOTES_LINUX5.0.txt
- reference to Driver/XFree86-4.2/ns2501.so)."

I think the theory sounds reasonable. I downloaded Feisty, and checked xorg.conf. It uses i810 driver, not intel. So I guess it was never supported. I've also tried other distributions like Tinyme, so it's not Ubuntu specific.
I did try the same thing as the person originally posting the bug, and vesa is not working either. I even tried safe graphics mode with Feisty, that did not work either (feels weird when normal graphics work, safe mode doesn't).
However I do have a vague feeling that I've gotten it to work with vesa in some version of puppy linux. Meaning that the vesa problem could be Ubuntu specific. Sadly beeing in the middle of moving houses, I can't get a hold of my linux discs. I also tried booting Slitaz, which worked beautifully. I know I've gotten it to work with Elive.

I guess that means support for the chip will have to be programmed for the intel driver, since it never supported it. I hope there is some help to be gained from i810, Elive or Slitaz in programming the intel driver. I don't know if it still should be called a bug, since it's more like adding a feature that was never supported by this driver. It is however a regression for some Ubuntu users if neither support for the chip is added, or the i810 driver is brought back. I know of no way to use the last two Ubuntu releases on my laptop without an external monitor.

[Tlinden-cc (tlinden-cc)]

Do I understand correctly that the old i810 driver relied on the VBIOS to initialize the DVO-LVDS?

Can the DVO chip be identified from the VBIOS dump?

Can the DVO chip be identified by running a software tool, without opening the machine?

Is the DVO chip separate from the 830MG chipset itself?

Which DVO chips are usually used on laptops with 830MG chipsets?

[Tlinden-cc (tlinden-cc)]

How is the framebuffer setting up the DVO LVDS transmitter chip? Is it using the Video BIOS or not?

[Tlinden-cc (tlinden-cc)]

I dumped the Video BIOS as strings using
  od -S 3 rom.bio
In this way I found the promising strings

NA-2501
CH-7009-A
NA-2501
NA-2501
National Semiconductor
2501
BMP_NSLVDS_StartNA-2501
BMP_NSLVDS_FPDATA
CH-7009-A
Chrontel Inc.
7009

The Chrontel CH-7009-A is supported by the ch7xxx driver and it is used within i830_dvo.c.

What about the National Semiconductor NA-2501 chip, does it have X.org support?
I think this is the National Semiconductor NA-2501 datasheet
  http://www.national.com/ds/DS/DS90C2501.pdf#page=1

The same strings are in the Video BIOS dump from Hernan Pastorizas S6110 too.

Kieron Gillespie could you please also dump the Video BIOS of your
Fujitsu Stylistic ST4110?

[Ciaran-gillespie (ciaran-gillespie)]

Created an attachment (id=26888)
Fujitsu Stylistic ST4110 Video ROM

Here is the video rom image for my fujitsu stylistic st4110.

[H Pastoriza (hpastoriza)]

I think Thomas has found the clue.
If you look for the logs the tfp410 driver complains
"tfp410 not detected got VID 1305: from DVOI2C_E Slave 112"
and from the datasheet of the DS90C2501 (page 17) the vendor ID is
13h 05h.

[Tlinden-cc (tlinden-cc)]

The Fujitsu Stylistic ST4110 Video ROM contains these strings
NA-2501
NA-2501
NA-2501
National Semiconductor
2501
BMP_NSLVDS_StartNA-2501
BMP_NSLVDS_FPDATA
so it is also using the same National Semiconductor 2501 chip as the Lifebook S 6110 and 6010.

[Tlinden-cc (tlinden-cc)]

The error message
  "ftp410 not detected got VID 1305: from DVOI2C_E slave 112."
is also found from a Fujitsu Stylistic 4120
http://www.linuxquestions.org/questions/gentoo-87/xorg.conf.new-for-fujitsu-stylistic-4120-730018/

So this means that there are at least four laptop models affected by this bug.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

A new major version of the -intel driver is now available in Karmic.

This version includes a major reworking of the acceleration
architecture, which resolves a huge number of issues. We do not know
whether it resolves the issue you reported.

Would you mind testing Karmic Alpha-2 and seeing if it is still a
problem? CD ISO images are available here:

  http://cdimages.ubuntu.com/releases/karmic/

If the issue can still be reproduced on karmic, please report here with
your findings, and attach a fresh Xorg.0.log from your test, and we will
be able to forward the bug upstream.

Otherwise, if the bug no longer exists in Karmic, let us know that as
well.

In the off chance you encounter different bugs while attempting to test
Karmic, please report those as new bug reports.

[chrome (chrome.x86)]

Unfortunately doesn't work on Karmic Alpha-2 too. Boot process looks the same as on Jaunty (as described in first message). Xorg message log looks similar as earlier - I'll post is soon.

[chrome (chrome.x86)]

Log file when running with Driver "intel" in xorg.conf

[chrome (chrome.x86)]

Log file when running with Driver "vesa" in xorg.conf

[chrome (chrome.x86)]

... and what I see on the terminal

[Bryce Harrington (bryce)]

Thanks for testing

[Bryce Harrington (bryce)]

Hi chrome,

I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=22699 - please subscribe to this bug report in case upstream needs further information or wishes you to test something. Thanks ahead of time.

[Gordon Jin (gordon-jin)]

*** Bug 22699 has been marked as a duplicate of this bug. ***

[Gilles Dartiguelongue (gilles-dartiguelongue)]

Got a ST4110 as well, found the NS2501 datasheet and started hacking. If I don't have something in a week, consider I failed at figuring out how this stuff works :)

[obedlink (obedlink-gmail)]

I have the same problem, but my laptop is a Dell Studio 1535, with Intel GM965 graphics, and Intel 965 Express chipset. I have this problem in ubuntu 8.04, 8.10, and the Ubuntu 9.10 beta 3

[Bryce Harrington (bryce)]

obedlink, no you don't; you might have similar symptoms but this bug is a hardware-specific issue and your hardware is as different from this one as can be. :-)

[Tlinden-cc (tlinden-cc)]

(In reply to comment #36)
> Got a ST4110 as well, found the NS2501 datasheet and started hacking. If I
> don't have something in a week, consider I failed at figuring out how this
> stuff works :)

Gilles, were you able to make any progress at all? If you would describe your problems, then maybe somebody might be able to help with solving them.

[Gilles Dartiguelongue (gilles-dartiguelongue)]

Uh yeah, sorry for keeping silent. So I managed to get the chip detected but reading registers 8 and 9 would fail the second time in init (I added some printf madness everywhere to see what the code was doing). Reading some recent discussions on the xorg mailing list, it might have been a problem in master (which my work is based on) so I'd need to rebase a see what's happening now.
I have been away from computers and will be tomorrow as well but I'll try to attach the patches on sunday so everyone can have a look.

[Tlinden-cc (tlinden-cc)]

(In reply to comment #38)
> Uh yeah, sorry for keeping silent. So I managed to get the chip detected but
> reading registers 8 and 9 would fail the second time in init (I added some
> printf madness everywhere to see what the code was doing). Reading some recent
> discussions on the xorg mailing list, it might have been a problem in master
> (which my work is based on) so I'd need to rebase a see what's happening now.
> I have been away from computers and will be tomorrow as well but I'll try to
> attach the patches on sunday so everyone can have a look.

OK, detecting the chip is already some progress. Please share your work so far-

[Gilles Dartiguelongue (gilles-dartiguelongue)]

Created an attachment (id=28441)
0001-Initial-support-for-NS2501-LVDS-driving-chip.patch

Sorry, this slipped again. Anyway here is the rough thing I'm working on.

[Tlinden-cc (tlinden-cc)]

It seems that the Intel Embedded Graphics Driver driver has a NA-2501 driver since it mentions Driver/XFree86-4.2/ns2501.so:
                          Release Notes for the
               Intel(R) Embedded Graphics Driver for Linux*
                 Version 5.1 Gold Release, June 2006

   http://downloadmirror.intel.com/9871/ENG/relnotes_Linux_5_1.txt

Is the source for this ns2501.so driver available somewhere? It might be useful for developing Gilles patch further.

[Gordon Jin (gordon-jin)]

*** Bug 23432 has been marked as a duplicate of this bug. ***

[yakuizhao (yakui-zhao)]

As the 830M chipset is not widely used and there is no corresponding specfic for DVO configuration, this bug will be rejected and marked as "WILLNOTFIX".
Thanks

[G8RB8 (jim-bailey)]

Same symptoms on Stylistic 4110. Framebuffer driver works, but slow. Switching to TTY with ctrl-alt-f1 gives a very low resolution screen with the cursor several lines off the bottom of the screen. Adding vga=791 to the GRUB menu.conf gives a 1024x768 console screen which is usable.

[G8RB8 (jim-bailey)]

Is there any chance the driver can be modified to use the resolution specified in xorg.conf? I think that would make it usable. Failing that where can I find instructions for the downgrade suggested above?

[G8RB8 (jim-bailey)]

Not to flog a dead horse, but is
Section "Device"
      Option "ForceEnablePipeA" "true"
EndSection
still available in the driver?

[Mereandor (mereandor)]

I don't see that this chipset is not widely used anymore. In the contrary: Up to now I found 5 bug reports on ubuntu only that seem to report this issue. Some of this bug reports have existed for years:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/238105
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/272560
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/257711
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/362582
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/306849

I'm sure though that there are lots of people who have the same problem and never look up the bug reports but simply stay with windows because linux "doesn't work" for them.

The last comments showed at least some progress in the area of discovering how this chip works, so I don't understand why this bug is closed as wontfix.

[Roman Zimmermann (torotil)]

The corresponding bug report on freedesktop.org was closed as WONTFIX because "...the 830M chipset is not widely used and there is no corresponding specfic for DVO configuration... " ( https://bugs.freedesktop.org/show_bug.cgi?id=17902 )

So except we get them to reopen this bug there is no chance that systems with this chipset will ever work on newer linux distributions.

[Theppitak Karoonboonyanan (thep)]

(In reply to comment #44)
> I don't see that this chipset is not widely used anymore. In the contrary: Up
> to now I found 5 bug reports on ubuntu only that seem to report this issue.
> Some of this bug reports have existed for years:

Thanks for reopening it. I was about to request for this action, too.

> I'm sure though that there are lots of people who have the same problem and
> never look up the bug reports but simply stay with windows because linux
> "doesn't work" for them.

For me, I'm fortunate to have installed a very old i810 driver (from Debian sarge version, IIRC) and pinned it at that version. This makes the video work. But as xorg has been developed, I've long suffered from broken XKB support and many other things. And I can't upgrade many GNOME packages due to the dependencies.

> The last comments showed at least some progress in the area of discovering how
> this chip works, so I don't understand why this bug is closed as wontfix.

Would some code from the old i810 driver help? I don't know about X video driver internals. Just hope (and pray) it helps.

[Tlinden-cc (tlinden-cc)]

Reading the X Linux Graphics Drivers from Intel website at
  http://intellinuxgraphics.org/documentation.html
one finds the section
  Supported Hardware
  The Linux graphics drivers from Intel support the following Intel® chipsets:
that lists
  i830M 82830 Chipset Graphics Controller
so the National Semiconductor 2501 driver should be implemented to fix this problem seen on several laptop models.

The Intel binary driver for the National Semiconductor 2501 chip ns2501.so, mentioned in comment #41 is actually available in binary form at
  http://www.spacechimp.net/rm4100/video/IEGD/IEGD_6_1_Linux/Driver/XFree86-4.3/
Could Intel publish the source for it as it might be useful with Gilles patch in comment #40?

[Tlinden-cc (tlinden-cc)]

By doing an octal dump with
  od -s 3 ns2501.so
one can see that this driver consists of the files:
  0034073 ns2501.c
  0034104 read_i2c_reg
  0034121 write_i2c_reg
  0034137 ns2501_driver
  0034155 ns2501_driver_mem
  0034177 ns2501_version
  0034216 ns2501_data.c
and there seems to be the entry points
  0003071 ns2501_exit
  0003105 ns2501_validate
  0003125 ns2501_get_attrs
  0003146 ns2501_get_timing_list
  0003175 ns2501_modes
  0003212 ns2501_1280x768_modes
  0003240 ns2501_get_port_status
  0003267 ns2501_get_power
  0003310 ns2501_init_device
  0003333 lpd_error
  0003345 ns2501_close
  0003362 pd_free
  0003372 ns2501_save
  0003406 pd_malloc
  0003420 pd_memset
  0003432 ns2501_regs
  0003446 ns2501_set_power
  0003467 pd_usleep
  0003501 ns2501_restore
  0003520 ns2501_post_set_mode
  0003545 ns2501_set_mode
  0003565 ns2501_set_attrs
  0003606 pd_get_attr
  0003622 ns2501_open
  0003636 ns2501_attrs
  0003653 pd_memcpy
  0003665 ns2501_init
  0003701 pd_strcpy
  0003713 ns2501_dab_list
  0003733 pd_register
  0003747 ns2501_num_regs
so there exists already code that could be reused and added to the present X Intel driver.

[Tlinden-cc (tlinden-cc)]

Actually the ns2501.so binary driver is available from
  http://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/16751/eng/IEGD_9_0_2_GOLD_1203.Exe&agr=&ProductID=&DwnldId=16751&strOSs=&OSFullName=&lang=eng

contained in the tarball
  IEGD_9_0_2_Linux.tgz
The file
  RELNOTES.txt
says
  ======================================================================
  Release Notes for the
  Intel(R) Embedded Graphics Drivers (IEGD)
  with Configuration Editor (CED) Package

  Version 9.0 Beta Release
  May, 2008
  ======================================================================
and
  Linux: System Requirements
  ==========================

  This package includes drivers built for the following X servers:

          XFree86 version 4.3.0
          X.org version 6.7, 6.8, 7.0, 7.1, & 7.2
so the ns2501.so is also available for X.org and not only for XFree86.

[G8RB8 (jim-bailey)]

Very relieved to see this re-opened. I SO want to get Ubuntu Netbook Remix running on my Stylistic 4110.
Any help getting it going is appreciated.
Any help needed I will try to provide, but I'm not a programmer. I can follow technical instructions though.

[G8RB8 (jim-bailey)]

Yea! It's re-opened!

[robe (r-evert)]

Yeah.

[chungyan5 (yan-amonics)]

hi all

I have already downgraded my Fujitsu S6010 to ubuntu 8.04 and xserver-xorg-video-i810_1.7.4-0ubuntu7_i386.deb, it is work very stable and fine. So i will not upgrade it anymore again in any future. 830M chipset is closed in update system, such as ubuntu 9.04 and 9.10. I upgraded to them and cannot work very good. So my current stable configuration seems as Fujitsu S6010 can do it best already.

good luck.

[Gilles Dartiguelongue (gilles-dartiguelongue)]

I try to give it a shot again but I'm still blocked at the same point I was last time, running X -verbose with a couple of added debugging message, I get:

(II) Loading /usr/lib/xorg/modules/drivers//ns2501.so
(II) Module ns2501: vendor="X.Org Foundation"
 compiled for 1.6.2, module version = 1.0.0
(II) intel(0): I2C bus "DVOI2C_B" removed.
(II) intel(0): I2C bus "DVOI2C_E" initialized.
(II) intel(0): ns2501_init
(II) intel(0): ns2501 Reading ID.
(II) intel(0): ns2501 READ BYTE, addr 0
(II) intel(0): ns2501 READ BYTE, addr 0, value is: 05
(II) intel(0): ns2501 READ BYTE, addr 1
(II) intel(0): ns2501 READ BYTE, addr 1, value is: 13
(II) intel(0): ns2501 READ BYTE, addr 0
(II) intel(0): ns2501 READ BYTE, addr 0, value is: 05
(II) intel(0): ns2501 READ BYTE, addr 2
(II) intel(0): ns2501 READ BYTE, addr 2, value is: 26
(II) intel(0): ns2501_init FINAL
(II) intel(0): I2C device "DVOI2C_E:NS2501 LVDS Controller" registered at address 0x70.
(II) intel(0): Output LVDS has no monitor section
(II) intel(0): ns2501_save
(II) intel(0): ns2501 READ BYTE, addr 8
(II) intel(0): ns2501 READ BYTE, addr 8, value is: 31
(II) intel(0): ns2501 WRITE BYTE, addr 8: 39
(II) intel(0): ns2501 READ BYTE, addr 9
(II) intel(0): ns2501 READ BYTE, addr 9, value is: bf
(II) intel(0): ns2501 WRITE BYTE, addr 9: 95
(II) intel(0): ns2501 READ BYTE, addr 12
(II) intel(0): ns2501 READ BYTE, addr 12, value is: 00
(II) intel(0): I2C bus "CRTDDC_A" initialized.
(II) intel(0): I2C bus "CRTDDC_A" removed.
(II) intel(0): ns2501_dpms
(II) intel(0): ns2501 READ BYTE, addr 8
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(II) intel(0): ns2501_detect
(II) intel(0): ns2501 READ BYTE, addr 9
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(II) intel(0): ns2501_detect, get bf
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS disconnected
(WW) intel(0): No outputs definitely connected, trying again...
(II) intel(0): Output VGA disconnected
(II) intel(0): Output LVDS disconnected
(WW) intel(0): Unable to find initial modes
(EE) intel(0): No valid modes.
(II) intel(0): ns2501_dpms
(II) intel(0): ns2501 READ BYTE, addr 8
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(II) intel(0): ns2501_restore
(II) intel(0): ns2501 WRITE BYTE, addr 8: 30
(II) intel(0): ns2501 WRITE BYTE, addr 9: bf
(II) intel(0): ns2501 WRITE BYTE, addr 12: 00
(II) intel(0): ns2501 WRITE BYTE, addr 8: 31
(II) Unloading /usr/lib/xorg/modules/drivers//ns2501.so
(II) Unloading /usr/lib/xorg/modules/drivers//ivch.so
(II) Unloading /usr/lib/xorg/modules/drivers//ch7xxx.so
(II) Unloading /usr/lib/xorg/modules/drivers//sil164.so
(II) Unloading /usr/lib/xorg/modules//libvgahw.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found

=========================================

I still don't understand why the driver can't read in ns2501_dpms function while it works elsewhere in the code. Also, I tried to find iegd sources but could only find binaries and I had a look at desassembling it but I'm really a n00b at that. Please help me understand the problem.

[Tlinden-cc (tlinden-cc)]

Gilles, could you please post here your recipe for compiling the driver you are working on? I would be interested in compiling it to try it myself.

[Mereandor (mereandor)]

I have an old laptop (Fujitsu Siemens S6010) that is affected by this bug.
It has a slightly defective keyboard but is functioning well except that. So it would be possibly to use it as a test machine.
I would send it to anybody who's willing to reimplement support for DVO-chip and needs a machine for testing.

Please contact me via e-mail to discuss further details if you would like to accept this offer.

[OiPenguin (lars-andreas-kvisle)]

Lucid beta 1 tested on Fujitsu S6010 and confirmed non-working. The issue present in previous releases appear to persist in 10.4.

[Chris Halse Rogers (raof)]

It looks like there's been some progress on this upstream, but not enough to make it into Lucid.

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=34807)
Xorg.0.log using intel driver and ns2501 patch

[Tlinden-cc (tlinden-cc)]

I tested the ns2501 patch that Gilles Dartiguelongue wrote and it works on my Fujitsu Siemens S6010 Lifebook! Thank you very much Gilles! This is very good progress finally! I hope we can figure out why it does not work on your laptop and to improve the patch to have it included upstream.

This is my recipe for compiling Gilles Dartiguelongues patch on Fedora
12 with kernel 2.6.32.10-90.fc12.i686.

The last version which contains the directories for Gilles patch is
xf86-video-intel-2.9.1. Later versions of the Intel driver require
kernel mode setting, so the patch cannot be applied since the directories have been moved.

Get the source of xf86-video-intel-2.9.1 with
wget http://ftp.x.org/pub/individual/driver/xf86-video-intel-2.9.1.tar.gz
tar -xvzf xf86-video-intel-2.9.1.tar.gz
cp -ax xf86-video-intel-2.9.1 b

Apply Gilles patch

patch -p0 -i 0001-Initial-support-for-NS2501-LVDS-driving-chip.patch
cd b

On Fedora 12 I had to make the following changes in ns2501.c to Gilles
patch in order to make it compile
comment out
  #include "xf86Resources.h"
replace
  #include <X11/extensions/dpms.h>
with
  #include <X11/extensions/dpmsconst.h>
  #include <X11/extensions/dpmsproto.h>

Compile the modules with:
  autoconf
On Fedora 12 I get an error message about the version of automake so I
need to run
  autoreconf
  ./configure --prefix=/tmp/intel-test
  make
  make install

Then the new modules need to be taken into use
cp /tmp/lib/xorg/modules/drivers/ns2501.so /usr/lib/xorg/modules/drivers/
mv /usr/lib/xorg/modules/drivers/intel_drv.so /usr/lib/xorg/modules/drivers/intel_drv.so_F12_org
cp /tmp/lib/xorg/modules/drivers/intel_drv.so /usr/lib/xorg/modules/drivers/

With these changes X starts with the intel driver. Glxgears works, but etracer crashes X. Also the beta version of the EVO videoconferencing system uses 3D-graphics which crashes X11.

The output from xrandr is strange since it claims that both outputs are disconnected, while in fact the LVDS does work.

xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA disconnected (normal left inverted right x axis y axis)
LVDS disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
  1024x768 (0x43) 65.0MHz
        h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.4KHz
        v: height 768 start 771 end 777 total 806 clock 60.0Hz

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=34808)
xorg.conf using the intel driver

[Tlinden-cc (tlinden-cc)]

In the attached /var/log/Xorg.0.log logfile there are the error messages

grep \(EE /var/log/Xorg.0.log
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(EE) intel(0): sil164 not detected got 5: from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.
(EE) intel(0): ns2501 Unable to read from DVOI2C_E Slave 112.

but apparently they are not fatal. In my BIOS settings I have presently set that I get output both to the internal and external screens. Gilles have you tried doing that?

[Tlinden-cc (tlinden-cc)]

If I attach an external monitor to the VGA connector, then it is recognized by xrandr, but I have not yet been able to enable the external display.

xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA disconnected (normal left inverted right x axis y axis)
LVDS disconnected 1024x768+0+0 (normal left inverted right x axis y
axis) 0mm x 0mm
  1024x768 (0x43) 65.0MHz
        h: width 1024 start 1048 end 1184 total 1344 skew 0 clock
48.4KHz
        v: height 768 start 771 end 777 total 806 clock 60.0Hz

xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048
VGA connected (normal left inverted right x axis y axis)
   1600x1200 60.0 +
   1280x1024 75.0 60.0
   1280x960 75.0 60.0
   1152x864 75.0
   1024x768 85.0 75.0 70.1 60.0
   832x624 74.6
   800x600 85.1 72.2 75.0 60.3 56.2
   640x480 85.0 75.0 72.8 66.7 59.9
   720x400 70.1
LVDS disconnected 1024x768+0+0 (normal left inverted right x axis y
axis) 0mm x 0mm

xrandr --auto
xrandr: cannot find crtc for output VGA

system-config-display draws a thin blue line and then the LVDS display
is covered with a slowly changing greyish pattern, probably because the internal display is driven with a too high refresh rate.

If I boot the S6010 with an external monitor attached, then the internal display shows again the slowly changing greyish pattern.

So having dualhead working needs some more effort. Any hints on how to proceed would be appreciated.

[Tlinden-cc (tlinden-cc)]

Created an attachment (id=34840)
Xorg.0.log with Option "ModeDebug" "true"

[Tlinden-cc (tlinden-cc)]

At the moment it is more chance and good luck that the intel driver starts with Gilles patch. I have the same problem that after initialization the routine that should read the ns2501 registers only returns error messages from the I2C bus. I don't know if some other device is blocking the I2C bus or what the problem is. So far I have not found a workaround. It seems that the routine that writes to the I2C bus works though.

Has anyone else tried out Gilles patch?

[Undrwater (undrwater)]

I just tried adding the patch using your instructions, and everything seemed to go well. What I'm noticing now, though is that udev is creating the same symptoms that xorg did.

I'll have a look through my logs to see if I can find something relevant.

[Jesse Barnes (jbarnes-virtuousgeek)]

Reassigning to the community. If someone can find docs for this, writing support shouldn't be too hard.

[Bryce Harrington (bryce)]

[According to the upstream bug report, Intel is no longer doing development support for this chip and is leaving it to the community to implement the needed functionality. Its unclear but sounds like kernel kms/drm implementation work is needed, so moving this to the kernel as a wishlist bug, although given the age of the chip it's probably a WONTFIX here at the distro level, but I'll let the kernel team decide.]

[Eugeni Dodonov (eugeni)]

This issue is affecting a hardware component which is not being actively worked on anymore.

Moving the assignee to the dri-devel list as contact, to give this issue a better coverage.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 362582

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[EricDHH (ericdhh)]

I have sold away the machine, for my part this bug can be closed.

[Gilles Dartiguelongue (gilles-dartiguelongue)]

For the record, I'm still working on this from time to time.
I ported the patch to kernel land quite easily, but still can't figure out what is the problem with register read failures.

Example from a 3.3.1 kernel booted with i915.modeset=1 drm.debug=0x04:

Apr 15 17:52:11 mobilix kernel: [drm:ns2501_init], init ns2501 dvo controller successfully!
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x09 from i915 gmbus dpb:38.
Apr 15 17:52:11 mobilix kernel: [drm:ns2501_readb], Unable to read register 0x08 from i915 gmbus dpb:38.

I would really appreciate someone with drm/intel knowledge helping here.
Will post patches later (code is really not that different that my previous post about this).

[G8RB8 (jim-bailey)]

Thanks for working on this Gilles. I wish I could help.

[Daniel-ffwll (daniel-ffwll)]

You need to check where the dvo chip actually is, i915 has about 6 different i2c channels. The easiest way is to use one of the i2c-tools to detect chips on all the i2c buses that drm/i915 exposes.

[Gilles Dartiguelongue (gilles-dartiguelongue)]

Ok, I installed i2c-tools and here is what it sees:

# i2cdetect -l
i2c-0 i2c i915 gmbus disabled I2C adapter
i2c-1 i2c i915 gmbus ssc I2C adapter
i2c-2 i2c i915 GPIOB I2C adapter
i2c-3 i2c i915 gmbus vga I2C adapter
i2c-4 i2c i915 GPIOA I2C adapter
i2c-5 i2c i915 gmbus panel I2C adapter
i2c-6 i2c i915 GPIOC I2C adapter
i2c-7 i2c i915 gmbus dpc I2C adapter
i2c-8 i2c i915 GPIOD I2C adapter
i2c-9 i2c i915 gmbus dpb I2C adapter
i2c-10 i2c i915 GPIOE I2C adapter
i2c-11 i2c i915 gmbus reserved I2C adapter
i2c-12 i2c i915 gmbus dpd I2C adapter
i2c-13 i2c i915 GPIOF I2C adapter
i2c-14 smbus SMBus I801 adapter at 1880 SMBus adapter

Then I run i2cdetect -y on all i2c buses, but only 0 and 11 (and 14 but that's unrelated to our work here I guess) show something.

Here is the output for those two:

# i2cdetect -y 0
     0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: 60 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# i2cdetect -y 11
     0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- 61 -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

reserved and disabled does not sound right anyway. Am I doing it right ?

[Gilles Dartiguelongue (gilles-dartiguelongue)]

Ok, forget that, I rebooted without kms disabled and now I get 28 i2c/smbus devices (most likely duplicates). Now scanning:

i2c-9 i2c i915 gmbus dpb I2C adapter
i2c-10 i2c i915 GPIOE I2C adapter

gives:

# i2cdetect -y 9
     0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

and

# i2cdump -y 9 0x38
No size specified (using byte-data access)
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 31 97 81 ff 00 04 00 00 ??&g????1??..?..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40 .????????..?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 03 ff 00 28 88 88 00 00 00 00 00 00 ....?..(??......
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ?..?............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 ?..?????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 ..............?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00 .?=?........???.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03 .???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03 (?(??....?pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33 ......??.?. 3333
c0: 05 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00 ??.???.??.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 98 00 80 00 00 00 80 00 00 00 00 00 00 00 ..?.?...?.......
f0: 71 77 b3 90 00 00 00 88 0a 0f 0a 0a 0a 0a 0a 0a qw??...?????????

So 1305 and 6726 actually look like the first registers indicated in the datasheet.

[Daniel-ffwll (daniel-ffwll)]

Yeah, the second i2cdetect dump looks much more reasonable, and it looks like you've indeed found the right bus for your i2c device. So the next step is to use that one with dev_priv->gmbus[GMBUS_PORT_DPB] and see whether it works better.

Btw, the gmbus reserved and disabled don't really exist, 3.5 will kill them. And if you have quick questions I suggest you ask on irc, #intel-gfx on freenode, usually one of us is around.

[Gilles Dartiguelongue (gilles-dartiguelongue)]

I pushed the current state of the code here:
https://github.com/EvaSDK/linux/commit/d590f8631a2421ba6bcef7041888b3aa382f87c7

I commented out dpms code for testing, but given the power of the machine it was quite long to get that out already so I'll fix that later.

[Daniel-ffwll (daniel-ffwll)]

Created attachment 60416
drm driver reload script

Looks like you've made a start alright. As I've said, I've you're getting stuck somewhere, don't be afreaid to pop up on #intel-gfx on irc. To speed up the development you can also only reload the drm/i915.ko kernel module. It's a bit tricky, so I use the attached script (you still need to compile i915.ko and copy it into the right place, of course).

You also need to enable CONFIG_VT_HW_CONSOLE_BINDING, otherwise the fbcon unbinding won't work and you can't unload i915.ko. Also, a 2nd machine with ssh access is very nice in case the module-reloading failed - otherwise you'll just be starring at a blank screen.

[Chris Wilson (ickle)]

*** Bug 50303 has been marked as a duplicate of this bug. ***

[Thomas Richter (thor-math)]

Ok, I managed to cross-compile the patched kernel sources on a much faster x64 machine, so I now have an initrd and a vmlinuz with the patch in it. I won't have access to the machine until tomorrow.

Is this already supposed to do anything interesting, or would anyone just be interested in the debug output?

I also found a datasheet from national semiconductor for the DS90C2501, is this the right one?

[Thomas Richter (thor-math)]

Ok, so I now fiddled a little bit with the patched kernel and the i2c utilities. In fact, I do get "something like a picture" on this machine. By which I mean that the image is ripped apart, the borders aren't set correctly, but the LVDS is at least detected and the screen is not totally blank.

Playing with the i2c utilities showed that on this Fujitsu Siemens the ns2501 (and yes, it really is one) is on chip address 0x38 on bus number 6.

I played with i2cset here and there and could disable and enable the screen with register #8, bit #0, but I do not get a usable screen. I do not know enough about DVO chips to be of much help as far as the programming is concerned.

What else can be done from here that would help you?

I get the following from /var/log/messages:

[ 7.272103] [drm:intel_opregion_setup], graphic opregion physical addr: 0x0
[ 7.272113] [drm:intel_opregion_setup], ACPI OpRegion not supported!
[ 7.272140] [drm:i915_init_phys_hws], Enabled hardware status page
[ 7.272156] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 7.272162] [drm] Driver supports precise vblank timestamp query.
[ 7.272176] [drm:init_vbt_defaults], Set default to SSC at 66MHz
[ 7.272414] [drm:parse_general_features], BDB_GENERAL_FEATURES int_tv_support 1 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 48 display_clock_mode 0
[ 7.272430] [drm:parse_general_definitions], crt_ddc_bus_pin: 2
[ 7.272441] [drm:parse_sdvo_device_mapping], different child size is found. Invalid.
[ 7.272450] [drm:parse_device_mapping], different child size is found. Invalid.
[ 7.272476] [drm:intel_dsm_pci_probe], no _DSM method for intel device
[ 7.272516] [drm:intel_modeset_init], 2 display pipes available.
[ 7.272539] [drm:intel_modeset_init], plane 0 init failed: -19
[ 7.272555] [drm:intel_modeset_init], plane 1 init failed: -19
[ 7.272570] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 7.272899] device: 'card0-VGA-1': device_add
[ 7.272935] PM: Adding info for No Bus:card0-VGA-1
[ 7.274750] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[ 7.274763] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[ 7.275659] [drm:sil164_init], sil164 not detected got 5: from i915 gmbus dpb Slave 56.
[ 7.275676] i2c i2c-6: master_xfer[0] W, addr=0x76, len=1
[ 7.275686] i2c i2c-6: master_xfer[1] R, addr=0x76, len=1
[ 7.275921] i2c i2c-6: NAK from device addr 0x76 msg #0
[ 7.275961] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[ 7.275970] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[ 7.276900] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[ 7.276911] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[ 7.291048] [drm:ns2501_init], init ns2501 dvo controller successfully!
[ 7.291088] device: 'card0-DVI-I-1': device_add
[ 7.291138] PM: Adding info for No Bus:card0-DVI-I-1
[ 7.295247] i2c i2c-6: master_xfer[0] W, addr=0x38, len=1
[ 7.295260] i2c i2c-6: master_xfer[1] R, addr=0x38, len=1
[ 7.296382] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
[ 7.301363] [drm:intel_update_fbc],
[ 7.301375] [drm:i915_get_vblank_timestamp], crtc 1 is disabl...

[Daniel-ffwll (daniel-ffwll)]

> I played with i2cset here and there and could disable and enable the screen
> with register #8, bit #0, but I do not get a usable screen. I do not know
> enough about DVO chips to be of much help as far as the programming is
> concerned.
>
> What else can be done from here that would help you?

Every dvo chip works in a slightly different way, so the next step is
trying to figure out how to program this chip. I guess you could take
another dvo chip that also drives lvds as an example (e.g. ivch or
ch7017). Last time I've checked the patch it does only detect the dvo
chip and doesn't change anything with the modeset within the dvo chip.
So things should work if you use the exact same mode as the bios (and
otherwise you get bands/tearing or just a black screen).

[Thomas Richter (thor-math)]

Well, I do have a documentation from National Semiconductors, but there is nothing that would define frequencies or bandwidths - only the sync pulses can be set, and intput to syncs. So I played writing values into all other registers with i2cset, but with little success - not any change, actually, except for the mentioned register. Ok, and you could block off the screen as well by disabling the sync pulses (not much of a surprise, I guess).

However, leaving all that aside - I'm no longer able to talk to the chip, upon rebooting i2cdetect gave me all blanks on bus #6. I really wonder what is going on. Could it be that there is some additional "gating" going on that blocks off access to this chip unless another register is set? Is that typical?

[Daniel-ffwll (daniel-ffwll)]

On Tue, May 29, 2012 at 9:13 PM, <email address hidden> wrote:
> --- Comment #75 from <email address hidden> 2012-05-29 12:13:12 PDT ---
> Well, I do have a documentation from National Semiconductors, but there is
> nothing that would define frequencies or bandwidths - only the sync pulses can
> be set, and intput to syncs. So I played writing values into all other
> registers with i2cset, but with little success - not any change, actually,
> except for the mentioned register. Ok, and you could block off the screen as
> well by disabling the sync pulses (not much of a surprise, I guess).

Well, most lvds panels have a fixed mode they work at. We fake
different resolutions by using the hw scaler on the gpu's scanout
unit. Still, having a dvo chip without any means to adjust that sounds
a bit strange.

> However, leaving all that aside - I'm no longer able to talk to the chip, upon
> rebooting i2cdetect gave me all blanks on bus #6. I really wonder what is going
> on. Could it be that there is some additional "gating" going on that blocks off
> access to this chip unless another register is set? Is that typical?

We do have some parts of the mmio space that need unlocking, but i2c
devices should always respond. You might need to power cycle the
machine to get it out of limbo though (i.e. yank the battery).

[Thomas Richter (thor-math)]

Sorry if this sounds like a stupid question - but how come that i2cdetect only
sees one bus when booting with the vga frame buffer, but 7 with the i915drm
module in place? Is there anything I need to do to activate the remaining
busses (not devices! - that will be the next problem - it is also a problem that bus #6 does not always lists the ns2501).

A second remark is that I found that the documentation I have on the ns2501 does not include the registers for the scaler (*sigh*), so that's my fault. I'll see what I can find.

[Daniel-ffwll (daniel-ffwll)]

> --- Comment #77 from <email address hidden> 2012-05-29 14:05:28 PDT ---
> Sorry if this sounds like a stupid question - but how come that i2cdetect only
> sees one bus when booting with the vga frame buffer, but 7 with the i915drm
> module in place? Is there anything I need to do to activate the remaining
> busses (not devices! - that will be the next problem - it is also a problem
> that bus #6 does not always lists the ns2501).

We expose all the i2c lines that the gpu can drive as normal i2c
buses. Some are used to read the edid from vga connected screens,
others to communicate to dvo chips. Dunno why ns2501 doesn't show up
all the time for you.

> A second remark is that I found that the documentation I have on the ns2501
> does not include the registers for the scaler (*sigh*), so that's my fault.
> I'll see what I can find.

The scaler is on the gpu side. See the funky computations in
intel_lvds_mode_ fixup in intel_lvds.c and all the pfit_ values
computed in there (grep for these to get to the code that uses them).

[Thomas Richter (thor-math)]

But as the drm module is never loaded, the corresponding i2c devices are not exposed? Can I trigger this process manually without loading the drm module? The idea was to check which values the bios leaves behind, and then install the same (or similar) values.

Concerning the scaler, the 2501 datasheet mentiones that it includes a built-in scaler, though its interface is not described. "OEM manufacturers please contact your NS representative". Hmm. Do you mean that the built-in scaler is present, though its interface is driven by pins that are controlled by the GPU, and thus are not exposed to its own i2c interface?

[Gilles Dartiguelongue (gilles-dartiguelongue)]

Actually, last I read this datasheet, it said that we could obtain the programming guide from our local NS vendor. I think that's what we are missing to have a functional driver (like information about timings or order to set registers to get the desired effect).

I managed to have a working X but it was stuck to the same resolution used by the BIOS/bootloader (skipping writing to registers).

If someone wants to pursue NS to get the programming guide, please do.
Time has been a bit missing to me lately.

[Thomas Richter (thor-math)]

Well, I've got a bit futher:

1) One can get i2c access mostly reliable when the drm.debug option is set high. Thus, whether or not the i2c interface works is likely a matter of timing. Could it be that the bit-banging interface is too critical to reach the chip in all cases? If so, where could one set the timing?

2) I can get a stable picture by using the video bios to write the chip configuration for me. For this, use

$ vbetool post
$ vbetool vbemode set 280

I also performed an i2c dump with and without the mode set through the video bios:

Properly initialized through the video bios:

     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 35 95 81 ff 03 04 00 00 ??&g????5??.??..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40 .????????..?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 03 ff 00 44 88 88 00 00 00 00 00 00 ....?..D??......
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ?..?............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 ?..?????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 ..............?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00 .?=?........???.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03 .???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03 (?(??....?pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33 ......??.?. 3333
c0: 01 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00 ??.???.??.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 1a 00 80 00 00 00 80 00 00 00 00 00 00 00 ..?.?...?.......
f0: 86 eb ca 90 00 00 00 88 0a 00 0a 0a 0a 0a 0a 0a ????...??.??????

Improperly initialized (initially):
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 05 13 26 67 01 a5 19 a2 31 95 81 ff 03 04 00 00 ??&g????1??.??..
10: 00 a0 02 02 02 02 02 02 07 00 00 11 54 03 02 40 .????????..?T??@
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 03 ff 00 28 88 88 00 00 00 00 00 00 ....?..(??......
40: 80 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ?..?............
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
60: 11 00 00 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 ?..?????????????
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 18 00 ..............?.
80: ff 07 3d 05 00 00 00 00 00 00 00 00 10 02 10 00 .?=?........???.
90: ff 07 a0 02 00 00 05 00 00 00 88 00 24 00 25 03 .???..?...?.$.%?
a0: 28 01 28 05 84 00 00 00 00 04 70 4f 00 00 03 03 (?(??....?pO..??
b0: 00 00 00 00 00 00 09 03 00 a0 00 20 33 33 33 33 ......??.?. 3333
c0: 05 90 00 0f 03 16 00 02 02 00 00 00 00 00 00 00 ??.???.??.......
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 1a 00 80 00 00 00 80 00 00 00 00 00 00 00 ..?.?...?.......
f0: 8f 07 58 90 00 00 00 88 0a 00 0a 0a 0a 0a 0a 0a ??X?...??.??????

Differences are in registers 0x44 and 0xc0 which must contain 0x37 and 0x01, respectively.

Just using i2cset to def...

[Thomas Richter (thor-math)]

Got a step further. What one can do to get a stable picture is simply to disable the scaler.

For this, insert: in dvo_ns2501.c, in the function

static void ns2501_mode_set

the following line:

  ns2501_writeb(dvo, 0x08, NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN);

ns2501_dpms should also et the NS2501_8_BPAS bit.

Voila, I get a stable console at boot-up, and a 2D desktop. However, something still seems to be seriously broken outside of the control of the DVO driver. As soon as I start an X session, or a 3D application like tuxracer, the display vanishes. At that point, the DVO also vanishes from the i2c bus for reasons unclear to me. A vbetool post restores the i2cbus.

So at least there seems to be something seriously broken with the i2c communication on this board.

It also happenes that I could start the desktop, but something was wrong with EXA as characters were printed on top of each other (overlayed) instead of erased properly. glxgears seemed to work (at least once).

So what is it with the i2c bus on this system?

[Thomas Richter (thor-math)]

Finally, success!

I'm not quite sure why, but for reasons unclear to me the DVO chip only wants to talk if the PLL is enabled and running and the screen resolution fits. In addition, the system has apparently a "fake" VGA output that must be disabled to have the system working properly. Otherwise, the KMS layer seems to want to redirect the output to the VGA, and then drops dead, leaving an unusable screen (and DVO!) behind. I do not know yet whether the physical VGA connector works, but basically, here is the receipt:

1) Apply the patches I mentioned above. Especially, the bypass mode of the scaler must be set as its function is unclear.

static void ns2501_dpms(struct intel_dvo_device *dvo, int mode)
{
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);
  unsigned char ch;

  DRM_DEBUG_KMS("%s: Trying set the dpms of the DVO to %d\n",__FUNCTION__,mode);

  if (ns->reg_8_set) {
    ch = ns->reg_8_shadow;
  } else {
    ch = NS2501_8_PD | NS2501_8_BPAS | NS2501_8_VEN | NS2501_8_HEN;
  }

  if (mode == DRM_MODE_DPMS_ON)
    ch |= NS2501_8_PD;
  else
    ch &= ~NS2501_8_PD;

  ch |= NS2501_8_BPAS;

  if (ns->reg_8_set == 0 || ns->reg_8_shadow != ch) {
    ns->reg_8_set = 1;
    ns->reg_8_shadow = ch;
    ns2501_writeb(dvo, NS2501_REG8, ch);
  }
}

Here I added a shadow register which is likely not exactly necessary, though I wanted to avoid the i2c communication if not necessary.

2) There is still a bug in the ns2501 source in so far as the query function returns something unitialized if reading from the DVO fails. And it fails quite often.

static enum drm_connector_status ns2501_detect(struct intel_dvo_device *dvo)
{
  uint8_t reg9;
  enum drm_connector_status status = connector_status_unknown;
  struct ns2501_priv *ns = (struct ns2501_priv *)(dvo->dev_priv);

  DRM_DEBUG_KMS("%s: Trying to detect the connector status\n",__FUNCTION__);

  if (ns2501_readb(dvo, NS2501_REG9, &reg9)) {
    if (!(reg9 & NS2501_9_RSEN))
      status = connector_status_connected;
    else
      status = connector_status_disconnected;

    ns->reg_9_set = 1;
    ns->reg_9_shadow = reg9;
  } else if (ns->reg_9_set) {
    if (!(ns->reg_9_shadow & NS2501_9_RSEN))
      status = connector_status_connected;
    else
      status = connector_status_disconnected;
  }

  DRM_DEBUG_KMS("%s: Status is %d\n",__FUNCTION__,status);

  return status;
}

Again a shadow register was added.

3) The following kernel arguments should be added to disable the VGA output:

i915.modeset=1 video=VGA-1:1024x768d video=DVI-I-1:1024x768e

I'm not sure why the system behaives so strange otherwise, I'll try to dig a bit deeper, but I believe that there is some limitation with the i830 and its outputs. Probably I'll find a datasheet.

With the above modifications, you cannot, of course, scale the screen (resolution is fixed), though 3D acceleration works nicely.

The same trick might also apply to the IBM R31, I'll check later next week - it had similar issues.

(Is actually anyone reading this??? Is there a better way to supply patches?)

[Daniel-ffwll (daniel-ffwll)]

On Thu, Jun 7, 2012 at 3:21 AM, <email address hidden> wrote:
> (Is actually anyone reading this??? Is there a better way to supply patches?)

Well, if you have a patch that works somewhat attaching it to all the
relevant bugzillas is usually a good way to get test feedback.

If the entire thing works reasonably well (which for this old hw
equals 'it works for you somewhat', no high standards), please submit
the complete kernel patch with a nice changelog to the intel-gfx
mailing list so that it can be merged.
-Daniel

[G8RB8 (jim-bailey)]

Thor:
 Yes I can tell you that I read all of it. Unfortunately I can't do much to help though. I do want to thank you for working on this too.

[Thomas Richter (thor-math)]

Now I also got the scaler "pseudo-working" by inspecting which values the vesa BIOS leaves behind in the DVO and just copying these values. By now I can support 640x480, 800x600 and the native resolution, which is here 1024x768. Unfortunately, I do not have the right vesa BIOS data for the latter, and for anything else, so your milage may vary. Also, the scaler support is somehow hacky as the DVO first needs to be turned on by enabling the PLL by poking into the chipset registers (yuck!). It's really a beasty chip.

I will submit the patch to the mailing list later this day, here for your records:

diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/dvo.h linux-3.4.1/drivers/gpu/drm/i915/dvo.h
--- linux-3.4.1-orig/drivers/gpu/drm/i915/dvo.h 2012-06-01 09:18:44.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/dvo.h 2012-06-08 13:15:19.000000000 +0200
@@ -140,5 +140,6 @@ extern struct intel_dvo_dev_ops ch7xxx_o
 extern struct intel_dvo_dev_ops ivch_ops;
 extern struct intel_dvo_dev_ops tfp410_ops;
 extern struct intel_dvo_dev_ops ch7017_ops;
+extern struct intel_dvo_dev_ops ns2501_ops;

 #endif /* _INTEL_DVO_H */
diff -rup linux-3.4.1-orig/drivers/gpu/drm/i915/dvo_ns2501.c linux-3.4.1/drivers/gpu/drm/i915/dvo_ns2501.c
--- linux-3.4.1-orig/drivers/gpu/drm/i915/dvo_ns2501.c 2012-06-08 17:59:20.000000000 +0200
+++ linux-3.4.1/drivers/gpu/drm/i915/dvo_ns2501.c 2012-06-08 17:52:21.000000000 +0200
@@ -0,0 +1,544 @@
+/**************************************************************************
+
+Copyright © 2012 Gilles Dartiguelongue, Thomas Richter
+
+All Rights Reserved.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sub license, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial portions
+of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
+IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+**************************************************************************/
+
+#include "dvo.h"
+#include "i915_reg.h"
+#include "i915_drv.h"
+
+#define NS2501_VID 0x1305
+#define NS2501_DID 0x6726
+
+#define NS2501_VID_LO 0x00
+#define NS2501_VID_HI 0x01
+#define NS2501_DID_LO 0x02
+#define NS2501_DID_HI 0x03
+#define NS2501_REV 0x04
+#define NS2501_RSVD 0x05
+#define NS2501_FREQ_LO 0x06
+#define NS2501_FREQ_HI 0x07
+
+#define NS2501_REG8 0x08
+#define NS2501_8_VEN (1<<5)
+#define NS2501_8_HEN (1<<4)
+#define NS2501_8_DSEL (1<<3)
+#define NS250...

[G8RB8 (jim-bailey)]

Why invalid just when real progress is being made?

[Thomas Richter (thor-math)]

Now two weeks passed, I submitted five versions for a patch of this bug to the mailing list, one here in public, yet nothing shows up in the official git repository at all.

Is it just me or is nobody actually interested in getting this working?

[Daniel-ffwll (daniel-ffwll)]

(In reply to comment #86)
> Now two weeks passed, I submitted five versions for a patch of this bug to the
> mailing list, one here in public, yet nothing shows up in the official git
> repository at all.
>
> Is it just me or is nobody actually interested in getting this working?

I've replied to your last submission I've seen (Msg-Id: <email address hidden>) that the patch is still whitespace mangled. Please simply resubmit the patch (as an attachment, your mailer seem to eat patches).

[W-florijn-k (w-florijn-k)]

A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit 7434a255a5cf42819b7e42377f18aaa02f6be52b
Author: Thomas Richter <email address hidden>
Date: Wed Jul 18 19:22:30 2012 +0200

    drm/i915: Support for ns2501-DVO

[Cooool-loki (cooool-loki)]

Please help!
Here's my rom_loki.bin
have it listed two displays
NA-2501
CH-7009-A
how to solve this problem

[Cooool-loki (cooool-loki)]

Created attachment 69801
rom_loki.bin

[Cooool-loki (cooool-loki)]

Created attachment 69802
intel_drm_dumper

[Cooool-loki (cooool-loki)]

Created attachment 69803
lspci -v

My laptop model: Fujitsu Siemens FMV-610NU2

[Cooool-loki (cooool-loki)]

Created attachment 69804
dmesg.txt

dmseg.txt
kernel 3.7.0-rc4

[Daniel-ffwll (daniel-ffwll)]

Loki, if you have a regression with i830M dvo support, please file a new bug report. If it's just lack of support for a specific DVO chipset, we can't really help you.