Comment 115 for bug 362582

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.