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 define these registers alone does not seem to help,
though the "screen ripping" looks different. Register 0xc0 seems to be
related to the screen scaler, at least bits 7,2 and 0 do have a
function, though I do not know which.
With a couple of vbemode calls issued from a remote console, I could
play a round of tuxracer. Given that this is a 1Ghz Pentium III, 10 fps
are quite acceptable and I believe that this means that this is
accelerated video.
So basically, the dvo chip kernel module should "just" call the video
bios to set the screen to the proper dimensions, and should then the
chip untouched - this might properly work. Of course, you wouldn't have
xrandr support with all that as the resolution would stay fixed, but
there would be hardware acceleration.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/362582
Title:
[i830] [Needs DVO-LVDS] Installer unable to launch Xorg on Fujitsu
Stylistic ST4120PW
To manage notifications about this bug go to:
https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/362582/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
