Hi. The new version decides between display modes in a different way and sometimes old xorg.conf files or old versions of the Xserver don't allow that to work anymore. Can you post your xorg.conf and Xorg.0.log files? Thanks.

Created attachment 116762 [details]
Xorg.0.log after X server fails

Created attachment 116763 [details]
dmesg when X server fails

(In reply to Connor Behan from comment #1)

Hi Connor,

Pretty painful to post this message from a Pentium II 450 MHz computer since it is so slow . . .
I checked /usr/share/X11/xorg.conf.d, but there is no xorg.conf in this system.
I did attach Xorg.0.log and dmesg files to this bug report so that you can read through it.
   These are the interesting stuff from Xorg.0.log.

___________________________________________________________________

. . .

[   248.565] (II) R128(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[   248.565] (II) R128(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
[   248.565] (II) R128(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
[   248.565] (II) R128(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
[   248.566] (II) R128(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
[   248.566] (II) R128(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
[   248.566] (II) R128(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
[   248.566] (II) R128(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[   248.566] (II) R128(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
[   248.566] (II) R128(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz)
[   248.583] (II) R128(0): PLL parameters: rf=2950 rd=65 min=12500 max=40000; xclk=12000
[   248.583] (II) R128(0): Found CRT table, assuming VGA connector
[   248.583] (II) R128(0): Output VGA-0 has no monitor section
[   248.583] (II) R128(0): I2C bus "VGA-0" initialized.
[   248.583] (II) R128(0): I2C device "VGA-0:ddc2" registered at address 0xA0.
[   248.587] (II) UnloadModule: "r128"
[   248.588] (II) Unloading r128
[   248.588] (II) UnloadModule: "vbe"
[   248.588] (II) Unloading vbe
[   248.588] (II) UnloadModule: "int10"
[   248.588] (II) Unloading int10
[   248.588] (II) UnloadModule: "vgahw"
[   248.588] (II) Unloading vgahw
[   248.588] (EE) Screen(s) found, but none have a usable configuration.
[   248.588] 
Fatal server error:
[   248.589] no screens found
[   248.589] 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[   248.589] Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   248.589] 
[   248.599]  ddxSigGiveUp: Closing log
[   248.599] Server terminated with error (1). Closing log file.
___________________________________________________________________


The monitor I am using here is Dell E193FP (19 inch flat screen monitor).
I can also try an HP 21 inch CRT monitor or 17 inch Gateway flat screen monitor later.
Perhaps this issue is a monitor specific problem.

Regards,

Kevin Brace


> Hi. The new version decides between display modes in a different way and
> sometimes old xorg.conf files or old versions of the Xserver don't allow
> that to work anymore. Can you post your xorg.conf and Xorg.0.log files?
> Thanks.

Created attachment 116764 [details]
Xorg.0.log after X server fails with Gateway FPD1765 monitor

I wasn't planning to try this at this point, but after reading the Xorg.0.log message, I decided to try Gateway FPD1765 flat screen monitor to see what will happen.
Unlike Dell E193FP flat screen monitor, I can see the stuff on the screen (I do not see anything on the screen with the Dell monitor.), but X server still crashes.
It appears that Rage 128 Pro does not have a screen (?), so X server does not start.
From the Xorg.0.log when I attached the Gateway monitor.

___________________________________________________________________

. . .
[   138.805] (II) R128(0): PLL parameters: rf=2950 rd=65 min=12500 max=40000; xclk=12000
[   138.805] (II) R128(0): Found CRT table, assuming VGA connector
[   138.806] (II) R128(0): Output VGA-0 has no monitor section
[   138.806] (II) R128(0): I2C bus "VGA-0" initialized.
[   138.806] (II) R128(0): I2C device "VGA-0:ddc2" registered at address 0xA0.
[   138.810] (II) UnloadModule: "r128"
[   138.810] (II) Unloading r128
[   138.810] (II) UnloadModule: "vbe"
[   138.810] (II) Unloading vbe
[   138.811] (II) UnloadModule: "int10"
[   138.811] (II) Unloading int10
[   138.811] (II) UnloadModule: "vgahw"
[   138.811] (II) Unloading vgahw
[   138.811] (EE) Screen(s) found, but none have a usable configuration.
[   138.811] 
Fatal server error:
[   138.811] no screens found
[   138.811] 
. . .

___________________________________________________________________


The same symptom in terms of how X server fails as far as I am concerned.

Regards,

Kevin Brace

Created attachment 116809 [details]
xorg.conf to try

Oh, you are going to need an xorg.conf. Here's an example one you can try.

Created attachment 116812 [details]
xorg.conf I used based on your sample version (1)

I made modifications to your original version due to the fact that I am using a desktop version Rage 128 Pro in my system.

Created attachment 116813 [details]
Corrected version of xorg.conf I used based on your sample version (1)

There was an error in the first modified version of the xorg.conf, so I made the correction.
This time no more syntax errors.

Created attachment 116814 [details]
Xorg.0.log after X server fails with the corrected version of xorg.conf (1)

This is the output of the Xorg.0.log with the corrected version of xorg.conf.
Again, the xorg.conf is based on your original version with my own modifications for AGP version Rage 128 Pro 32 MB.

(In reply to Connor Behan from comment #7)

Hi Connor,

I downloaded your original version for your IBM ThinkPad you use for your development purposes, made some modifications I felt appropriate for AGP version Rage 128 Pro 32 MB.
I installed the modified xorg.conf under /usr/share/X11/xorg.conf.d.
I posted the code for you to see.
It is possible that I removed too much information, but unfortunately, I did not see a difference in the outcome.
X server still crashes during boot.
I can see something on the screen with Alt + F1 (terminal screen), but manually restarting X server still causes a crash.
    I will assume that I need to specify a screen resolution with the correct color depth manually.
I will try that next, although it will be helpful if you can write a sample xorg.conf for desktop version Rage 128 / 128 Pro.
I do have current access to 16 MB version (Rage 128 AGP) and 32 MB version (Rage 128 Pro AGP).
    I probably should not ask for too much, but is it possible that you can modify your x.org code in the long run so that it does not have to rely on xorg.conf?
I assume many other people probably want monitor detection to be Plug & Play (It used to be a huge marketing term in the computer industry back when Windows 95 was so big . . .).
I would imagine that my Lubuntu installation did not have xorg.conf to begin with because xorg.conf has become deprecated as a way to detect and set monitor configuration.
Since the chip itself supports VESA DDC for monitor detection, I would imagine that the information gathered from DDC should be used to figure out the monitor screen resolution support, and the x.org device driver should probably try to use that information rather than relying on a text file.
I will post another message on my development wish list so that these features can be supported in the future.

Regards,

Kevin Brace


> Created attachment 116809 [details]
> xorg.conf to try
> 
> Oh, you are going to need an xorg.conf. Here's an example one you can try.

Created attachment 116823 [details]
xorg.conf I used based on your sample version (2)

My second version xorg.conf which more closely resembles your original version.

Created attachment 116824 [details]
Xorg.0.log after X server fails with the corrected version of xorg.conf (2)

This is the output of the Xorg.0.log with the second version of xorg.conf.
I "had to" specify my Dell E193FP monitor, but I think it made no difference.

(In reply to Connor Behan from comment #7)

Hi Connor,

Okay, I tried it for the second time.
This time, I tried not to change your xorg.conf as much as possible.
It forced X server to use 16-bit color instead of the default 32-bit color.
I even went ahead to specify my Dell E193FP monitor (I do not like doing this since people *DO* change monitors in desktop environments unlike the laptop you use with only one particular monitor type.), but it did not appear to make any difference.
This is the portion of the Xorg.0.log I am concerned about.

________________________________________________________________________

. . .
[    43.536] (II) R128(0): EDID vendor "DEL", prod id 28686
[    43.537] (II) R128(0): Using hsync ranges from config file
[    43.537] (II) R128(0): Using vrefresh ranges from config file
[    43.537] (II) R128(0): Printing DDC gathered Modelines:
[    43.537] (II) R128(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz)
[    43.537] (II) R128(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
[    43.537] (II) R128(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
[    43.537] (II) R128(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
[    43.538] (II) R128(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
[    43.538] (II) R128(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
[    43.538] (II) R128(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz)
[    43.538] (II) R128(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
[    43.538] (II) R128(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
[    43.538] (II) R128(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz)
[    43.555] (II) R128(0): PLL parameters: rf=2950 rd=65 min=12500 max=40000; xclk=12000
[    43.555] (II) R128(0): Found CRT table, assuming VGA connector
[    43.555] (II) R128(0): Output VGA-0 using monitor section Monitor0
[    43.555] (II) R128(0): I2C bus "VGA-0" initialized.
[    43.555] (II) R128(0): I2C device "VGA-0:ddc2" registered at address 0xA0.
[    43.560] (II) UnloadModule: "r128"
[    43.560] (II) Unloading r128
[    43.560] (II) UnloadModule: "vbe"
[    43.560] (II) Unloading vbe
[    43.560] (II) UnloadModule: "int10"
[    43.560] (II) Unloading int10
[    43.560] (II) UnloadModule: "vgahw"
[    43.560] (II) Unloading vgahw
[    43.560] (EE) Screen(s) found, but none have a usable configuration.
. . .
________________________________________________________________________

It appears that your x.org r128 device driver is able to read VESA DDC information from the Dell monitor.
That being said, I used your xorg.conf, so it appears to ignore the monitor's frequency range.
Still, somehow the device driver is getting unloaded (see [    43.560] (II) UnloadModule: "r128"), hence, there is no graphical screen, hence, X server refuses to start.
It appears that this issue has nothing to do with specifying a screen resolution.
How do I analyze the issue further from hereon?
Why is the device driver getting unloaded?
How do I debug your x.org r128 device driver?
I do have some free time, low level hardware programming experience (x86 assembly language, and C/C++ language, Windows kernel device driver development and debug experience.), and PCI device hardware design experience, so if you can give me guidance on how to trace and debug the an x.org device driver on Linux, that will be very helpful.

Regards,

Kevin Brace


> Created attachment 116809 [details]
> xorg.conf to try
> 
> Oh, you are going to need an xorg.conf. Here's an example one you can try.

Hi, model names that appear in xorg.conf have no effect so the majority of people only have to write it once. I already thought that the xorg.conf I posted would work for you. And if it worked, the next steps would be changing depth 16 to 24, changing 1024x768 to 1280x1024, etc. Clearly though, there's still a problem with the driver. I have an idea of a debugging patch to send you. It should be ready later today.

To this day, modern cards still require a bit of xorg.conf text if you want to use them with UMS drivers. For example, code for telling Radeon / R128 / Mach64 apart was never added to http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/xf86pciBus.c#n1064. You can ask for this on the xorg-devel list if you want. But more importantly, people with old cards should put screen resolutions in xorg.conf. This is not for telling the driver which modes to support. It's for telling the driver which modes NOT to support. Xrandr allows you to increase the resolution without restarting X. So even if you want to use 1024x768, you could plug in a monitor that supports 1920x1080. In this case, X would reserve a huge chunk of video RAM, just in case you decide to switch to this mode later. It would likely be too much for r128 cards to handle.

So contrary to all the rumours, xorg.conf is not deprecated. It's just something that only power users are supposed to write now that high memory cards and KMS drivers are common.

Created attachment 116837 [details] [review]
First debug pach to try

Hi, can you recompile the driver with this patch and then post the log? This checks to see if it's failing in the function that gave me the most trouble. If it is, we will have to try a bunch of pin combinations.

Created attachment 116840 [details]
Xorg.0.log after X server fails with the first patch applied version of r128 x.org device driver

I checked the Xorg.0.log, and the message it displays appears a little different than the non-debug version.

Created attachment 116843 [details]
Xorg.0.log after X server fails with the first patch applied version of r128 x.org device driver (3)

I checked the Xorg.0.log, and the message it displays appears a little different than the non-debug version.
It appears that the patch worked (first time I ever tried such a thing).

Created attachment 116844 [details]
xorg.conf I used with the first patch applied version of r128 x.org device driver (3)

(In reply to Connor Behan from comment #16)

Hi Connor,

Okay, it is very late, but I stayed up a little longer to apply the patch, and recompile the x.org r128 device driver.
Based on what I saw on Xorg.0.log, it appears that the patch "worked." (Again, I have never done applying a patch on anything, so this is the first time I tried this.)
For those who have never done such a thing (I assume there are many other people like that.), this is how I did it.

1. Download the patch file to /"your x.org r128 source code installation path"/xf86-video-r128

2. Apply the patch (If the patch file name is different, edit "0001-Debug-try-1.patch" portion.)

_________________________________________________________________

patch -p1 < 0001-Debug-try-1.patch
_________________________________________________________________

3. Become a root

_________________________________________________________________

sudo su

_________________________________________________________________

4. Clean up the old stuff

_________________________________________________________________

make clean
_________________________________________________________________

5. Generate a new make file

_________________________________________________________________

./autogen.sh --prefix=/usr --enable-dri
_________________________________________________________________

6. Compile the x.org r128 device driver

_________________________________________________________________

make
_________________________________________________________________

7. (Optional) Make a back up of the original r128_drv.so

_________________________________________________________________

cd /usr/lib/xorg/modules/drivers
mv r128_drv.so Original_r128_drv.so
_________________________________________________________________

8. Install the newly built x.org r128 device driver

_________________________________________________________________

make install
_________________________________________________________________

9. Stop being a root

_________________________________________________________________

exit
_________________________________________________________________

10. Reboot


Hopefully, you can now figure out what is going on.

Regards,

Kevin Brace


> Created attachment 116837 [details] [review] [review]
> First debug pach to try
> 
> Hi, can you recompile the driver with this patch and then post the log? This
> checks to see if it's failing in the function that gave me the most trouble.
> If it is, we will have to try a bunch of pin combinations.

Created attachment 116846 [details] [review]
Second debug patch to try

Sounds good. My theory for which cards use which DDC pins seems to have failed. With the first debug patch still applied, can you apply this one on top of it and then post the log?

Created attachment 116851 [details]
Xorg.0.log after X server fails with the second patch applied version of x.org r128 device driver (4)

(In reply to Connor Behan from comment #21)

Hi Connor,

Okay, I posted the Xorg.0.log results from the second patch applied version of the device driver.
I am looking at the VESA DDC address used by r128 x.org DDX device driver, isn't it supposed to be MMIO address 0x0068 instead of 0x0060?

______________________________________________________________________

[    45.922] (II) R128(0): I2C device "VGA-0:E-EDID segment register" registered at address 0x60.
______________________________________________________________________

There is a register called GPIO_MONID which sounds like is related to VESA DDC (If I am correct, a variant of I2C bus.), but the address should be 0x0068 instead of 0x0060 identified by the device driver.
Although the Xorg.0.log does not say so, MMIO address 0x006C is also VESA DDC related (GPIO_MONIDB).
Maybe the address of the VESA DDC / AppleSense is off by 8 positions, hence, the device driver is having monitor detection issues.
The operation of these registers appear to change when LCD display is used, so you may have to have a way to distinguish regular PC card, x86 laptop, and Apple Mac depending on the situation.

Regards,

Kevin Brace


> Created attachment 116846 [details] [review] [review]
> Second debug patch to try
> 
> Sounds good. My theory for which cards use which DDC pins seems to have
> failed. With the first debug patch still applied, can you apply this one on
> top of it and then post the log?

Created attachment 116855 [details] [review]
Likely fix

Hi Kevin,

I used to think that until I saw that the 0x0060 i2c address was hardcoded http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/ddc/ddc.c#n325. The problem is that I entered the wrong bits. I thought all r128 VGA ports used the same ones, but they don't. Single / dual head makes a difference.

I hope this patch works. On top of the git driver that is, without the debugging patches.

(In reply to Connor Behan from comment #24)

Hi Connor,

If you look at r128reg.h, these are the registers related to VESA DDC / AppleSense.
It starts at line 661, at least based on the version I have.

________________________________________________________________________
. . .
#define R128_GPIO_MONID                   0x0068
#       define R128_GPIO_MONID_A_0        (1 <<  0)
#       define R128_GPIO_MONID_A_1        (1 <<  1)
#       define R128_GPIO_MONID_A_2        (1 <<  2)
#       define R128_GPIO_MONID_A_3        (1 <<  3)
#       define R128_GPIO_MONID_Y_0        (1 <<  8)
#       define R128_GPIO_MONID_Y_1        (1 <<  9)
#       define R128_GPIO_MONID_Y_2        (1 << 10)
#       define R128_GPIO_MONID_Y_3        (1 << 11)
#       define R128_GPIO_MONID_EN_0       (1 << 16)
#       define R128_GPIO_MONID_EN_1       (1 << 17)
#       define R128_GPIO_MONID_EN_2       (1 << 18)
#       define R128_GPIO_MONID_EN_3       (1 << 19)
#       define R128_GPIO_MONID_MASK_0     (1 << 24)
#       define R128_GPIO_MONID_MASK_1     (1 << 25)
#       define R128_GPIO_MONID_MASK_2     (1 << 26)
#       define R128_GPIO_MONID_MASK_3     (1 << 27)
#define R128_GPIO_MONIDB                  0x006c
. . .
________________________________________________________________________


I will first test the "Likely fix" patch over the second debug patch.
Then I will apply the "Likely fix" patch over the one I get from freedesktop.org Git repository.
I will let you know shortly of the results.

Regards,

Kevin Brace 


> Created attachment 116855 [details] [review] [review]
> Likely fix
> 
> Hi Kevin,
> 
> I used to think that until I saw that the 0x0060 i2c address was hardcoded
> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/ddc/ddc.c#n325. The
> problem is that I entered the wrong bits. I thought all r128 VGA ports used
> the same ones, but they don't. Single / dual head makes a difference.
> 
> I hope this patch works. On top of the git driver that is, without the
> debugging patches.

Hi Connor,

I applied the "Likely fix" patch from you to the version I cloned from the freedesktop.org Git repository just now.
I did not use the second patch version code base.
Now the situation has worsened.
Although the OS itself did not completely crash, I can no longer even display anything on the screen through tty.
tty1 through tty6 are all dead (i.e., Alt + F1 through Alt + F6).
The OS is not completely dead since there definitely is some periodic hard drive access, but Ctrl + Alt + Del doesn't work either.
You may want to apply the "Likely fix" patch to make it compatible with second patch version code base, so that we can observe what goes on inside the device driver code.

Regards,

Kevin Brace

Hi Connor,

I actually have a new Xorg.0.log I will post shortly, but due to the instability issue I just mentioned, the size of the log is very large.
I will post a truncated version shortly.
Stay tuned.

Regards,

Kevin Brace

Created attachment 116858 [details]
Xorg.0.log with the likely fix patch applied (5)

Hi Connor,

Okay, take a look at the Xorg.0.log from r128 x.org DDX device driver with your "likely fix" patch applied.
It does appear to get through the monitor detection via VESA DDC portion, but now the device driver is getting into trouble dealing with CCE.
    Sometimes I am wondering how come the code base you worked on that got included with Lubuntu 14.04 works, but not when it got backported to Lubuntu 12.04 by me?
Anyway, I am sure you have a better idea of what is going on inside the device driver than myself, so I will let you figure out why CCE gets locked up in an infinite loop (This happened to be Apple's HQ street name in Cupertino, CA.).
Please note that Xorg.0.log was about 67 MB large due to the device driver continuously writing to Xorg.0.log (this explains the continuous access to the hard drive even though I can no longer control the computer itself), hence, I had to manually truncate the log file.
I will go deal with OpenChrome device driver related work until you have a new patch for me to test.

Regards,

Kevin Brace

The difference between the git version and 14.04's version is the RandR support. But that doesn't involve the CCE so I suspect the problem is due to external dependencies.

For example, the problem should go away if you disable DRI. However, DRI might be something you want. Did you have it working before? Does your system have everything else required for that support, like an r128_dri.so file? It might also help to see if "AccelMethod" "EXA" improves things.

Created attachment 116864 [details]
Xorg.0.log with the likely fix patch applied device driver along with DRI and EXA activated xorg.conf (6)

By activating DRI and EXA, Lubuntu 12.04 now boots!

Created attachment 116865 [details]
xorg.conf with DRI and EXA activated (6)

This is the xorg.conf I used with DRI and EXA activated.

(In reply to Connor Behan from comment #30)

Hi Connor,

Good news!
Okay, since you told me about DRI and EXA, I looked at the xorg.conf I used when I did the previous testing (See: xorg.conf I used with the first patch applied version of r128 x.org device driver (3)) to see if I have to disable DRI and EXA.
It turned out I omitted lines about them from the one I used, so I went back to your original, and put them back to see if that will make the difference.
Since you mentioned that your code change from the Ubuntu 12.04 code base to Ubuntu 14.04 code base for r128 is RandR support, I assumed that rest of the code (DRI related area) was not touched.
It turned out not activating DRI and EXA were the likely reason of the hang, and now my Lubuntu 12.04 does boot normally with the locally compiled device driver.
Next, I will like to backport the code to Lubuntu 10.04.
   However, as reported by Christopher Chavez (Bug #88767), I do see some rendering issues similar to what was reported by him, particularly screenshot 5 as he calls it.

https://bugs.freedesktop.org/attachment.cgi?id=112766

With the original "out of the box" x.org r128 DDX device driver that came with Lubuntu 12.04, I do not see any rendering bugs, although its rendering performance I feel is subpar compared to your version (This is noticeable when Lubuntu closes all the remaining windows when I shutdown. The rendering performance is definitely better now.).
Most typical issue I see with window rendering is the window display underneath the current one getting corrupted.
This appears similar to what Christopher reported.
I hope this rendering bug can be fixed fairly soon.
    I also did a screen resolution change from 1280 X 1024 to 1024 X 768, and saw something like a stuck hardware cursor object (Note: It does not resemble a mouse cursor. It appears to look like corrupted junk on the screen that changes the mouse cursor color when I move the mouse cursor over it.) the on the top left hand corner of the screen.
Does your current version code base use a hardware cursor for the mouse pointer?
Is this hardware cursor address conflicting with the frame buffer?
This issue definitely needs to be dealt with soon.
    I tried ACPI S1 State resume test (standby), and at least with the Intel 440BX chipset mainboard I have now, it did come out of standby correctly, and the corrupted junk stuck hardware cursor object disappeared.
I have not tested the device driver with ACPI S3 State yet (This mainboard does not support it. The mainboard I have that supports ACPI S3 State is not set up right now for use.).
    I do own several variations of Rage 128, so I can certainly help you with validation related work with my own hardware in order to help you fix these bugs I have observed.
I am also wondering why lspci still report that my Rage 128 Pro is still using aty128fb kernel module rather than a different kernel module.
What you have is not a frame buffer driver, so I am surprised that it is still called aty128fb.
lsmod command does tell me that I have a module called r128 installed.
For now, I think you can do a new commit on the change you made to your base code pretty soon, although I have a few more monitors at where I am right now, so I can test the improved code with several monitors I have on hand.
Perhaps then you can do a new commit to update the code.
You can add my name to the commit list if you wanted to.

Regards,

Kevin Brace


> The difference between the git version and 14.04's version is the RandR
> support. But that doesn't involve the CCE so I suspect the problem is due to
> external dependencies.
> 
> For example, the problem should go away if you disable DRI. However, DRI
> might be something you want. Did you have it working before? Does your
> system have everything else required for that support, like an r128_dri.so
> file? It might also help to see if "AccelMethod" "EXA" improves things.

Hi Connor,

Regarding the "corrupted junk" as I called it, it is definitely 100% reproducible.
All I have to do is to change my screen resolution from 1280 X 1024 to 1024 X 768 in Lubuntu 12.04 i386, and I see the junk on the screen.
When I right click over the "corrupted junk," the pop up windows gets corrupted over the area that is covered by the "corrupted junk."
When I tried to take a screen shot, the corruption does not show up in the screen shot, so I feel like it is hardware cursor related issue.
I can take a digital camera pictures if you want to take a look at it.

Regards,

Kevin Brace

Hi Kevin,

This sounds related to the hardware cursor and it can be toggled on and off with Option "SWcursor" "true" in the "Device" section.

Unforuntately, I have not learned anything new about the rendering errors since adding the EXA support. So my only advice is the same as what's in bug 88767. Namely Option "EXANoComposite" "true" in the "Device" section and Option "Composite" "false" in the "Extensions" section.

If you really want to experiment to get the hardware cursor working, it's controlled by this fairly simple function: http://cgit.freedesktop.org/xorg/driver/xf86-video-r128/tree/src/r128_cursor.c#n195

First, it is possible that I miscalculated the size of things. So by doubling some of the sizes (fairly harmless), you might be able to get the corruption to disappear. Also, you can read up on Xorg's HARDWARE_CURSOR_* flags and try different combinations. I added the ones that gave the best result for my card but if different ones work for your card, we can add some code that decides between the two.

Oh and about the kernel modules, r128 is the main one you need for DRI. It creates /dev/dri/card0. Another device, /dev/fb0 is created by aty128fb, a driver for the consoles you get by pressing Ctrl+Alt+F1,F2, etc. It makes their resolutions higher than the default ones provided by the kernel. KMS drivers combine these two functions into one module. It should be easy to turn them on and off in Ubuntu. Personally, I couldn't get aty128fb to work so I replace it with uvesafb with my r128 card.

(In reply to Connor Behan from comment #35)

Hi Connor,

I will slow down today on this issue since I practically spent the whole day yesterday doing testing, compilation, installation, and reading hardware programming documentation.
I will reduce my hours on this issue for today.
    I do understand that software cursor might be a workaround, I think your address mapping of the hardware cursor can be the problem, not the hardware cursor code in of itself.
You explained in this blog entry about how you map your hardware cursor.

http://smallperturbation.com/r128-exa

Do you have any debug code to look into the hardware cursor address, and see if it comes into conflict when the screen resolution changes?
It looks to me that is what is happening.
    Actually, I managed to compile your x.org DDX r128 device driver for Lubuntu 10.04 very early this morning, although I had to figure out how to overcome xorg-macros not being Version 1.8 error when generating the make file.
This page has the instructions on how to install xorg-macros Version 1.8.
This is where I got xorg-macros Version 1.8.

http://xorg.freedesktop.org/releases/individual/util/util-macros-1.8.0.tar.bz2

This posting gives very detailed instructions on how to install xorg-macros Version 1.8.

http://forums.linuxmint.com/viewtopic.php?f=42&t=110304

With xorg-macros Version 1.8 in place, I was able to compile your current iteration code with the VESA DDC patch applied prior to the compilation, and boot Lubuntu 10.04 with the proper xorg.conf.
Pretty much the instructions on how to compile and install is the same, however, I believe the location of xorg.conf is going to be different in Lubuntu 10.04 (it has to be located in /usr/lib/X11/xorg.conf.d).
I do not recall seeing the corrupted junk on the screen when changing screen resolution in Lubuntu 10.04, so maybe this issue is specific to Lubuntu 12.04.
Is it possible to make changes in your code so that an older version of xorg-macros can be used?
I will post detailed instructions on how to compile the source code for Lubuntu 10.04 later for other people interested in updating their device driver from the source code.
    I do not want to say anything harsh regarding the rendering errors, but if this were a product to be sold to the general public, this will be a job security issue (i.e., employment termination) if this much amount of bugs went into the code (i.e., too many customer returns of the graphics card).
Of course, I did not write the code, so I do not really have the right to criticize you too much.
Please note that I live in what people call Silicon Valley (travelling right now), so losing a job and being unemployed for a long period of time is very common even for engineering people in the computer / electronics industry (i.e., myself).
Corporations there literally throw engineers away all the time in the name of "cost cutting," but I will digress on that subject.
    I guess I will have to start studying how this EXA thing works so that I can help in the process of fixing the rendering issues.
To be honest, the rendering issue shows up everywhere in Lubuntu's GUI (i.e., very easy to reproduce) like when I pop up the program launcher, and move the mouse cursor up and down.
Personally, I will like to see bugs I have seen resolved prior to Ubuntu 16.04 LTS release since Canonical almost never updates their x.org DDX device drivers (Maybe they do update them, but I have not seen improvements in the past.).
    How do you even debug x.org DDX device driver in Linux?
Back in the days when I worked on my Windows kernel device driver, I used WinDbg (Windows Debugger) with a cross linked serial cable or FireWire (only for Windows XP SP1 and later) from the host computer to monitor the target computer that had the hardware / device driver running, but ultimately, it was fundamentally that "printf" type debugging.
I was able to debug my device driver with this for the most part (a few corner cases were impossible with this method, however).
Let me know how you debugged the DDX r128 device driver, so that I can start exploring the code.

Regards,

Kevin Brace


> Hi Kevin,
> 
> This sounds related to the hardware cursor and it can be toggled on and off
> with Option "SWcursor" "true" in the "Device" section.
> 
> Unforuntately, I have not learned anything new about the rendering errors
> since adding the EXA support. So my only advice is the same as what's in bug
> 88767. Namely Option "EXANoComposite" "true" in the "Device" section and
> Option "Composite" "false" in the "Extensions" section.
> 
> If you really want to experiment to get the hardware cursor working, it's
> controlled by this fairly simple function:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-r128/tree/src/r128_cursor.
> c#n195
> 
> First, it is possible that I miscalculated the size of things. So by
> doubling some of the sizes (fairly harmless), you might be able to get the
> corruption to disappear. Also, you can read up on Xorg's HARDWARE_CURSOR_*
> flags and try different combinations. I added the ones that gave the best
> result for my card but if different ones work for your card, we can add some
> code that decides between the two.

Created attachment 116892 [details]
xorg.conf with DRI and EXA activated (6)

(In reply to Kevin Brace from comment #38)

I updated the xorg.conf because there were some syntax errors in the file.


> Created attachment 116892 [details]
> xorg.conf with DRI and EXA activated (6)

(In reply to Kevin Brace from comment #37)
> (In reply to Connor Behan from comment #35)
> Do you have any debug code to look into the hardware cursor address, and see
> if it comes into conflict when the screen resolution changes?
> It looks to me that is what is happening.

That can't be it. The card is only told what addresses to use when the server starts up. It allocates the cursor once and never again. The front / back / depth buffers that it allocates in front of it are also big enough to fit any mode that X will let you switch to later. So none of the addresses will change or be overwritten.

Answering these might be useful. You say the cursor gets corrupted when you go from 1280x1024 to 1024x768. Does this mean you start off with 1280x1024 and switch to 1024x768 in mid-session using a randr client program? If so, do you still get the same error if you modify your xorg.conf to start off with 1024x768 resolution from the get-go? If so, see if the same thing still happens on a pre-randr version of the driver.

> Pretty much the instructions on how to compile and install is the same,
> however, I believe the location of xorg.conf is going to be different in
> Lubuntu 10.04 (it has to be located in /usr/lib/X11/xorg.conf.d).

I've never heard of an X version that didn't source /etc/X11/xorg.conf but if you think it's safer to move somewhere else, go for it.

> I do not recall seeing the corrupted junk on the screen when changing screen
> resolution in Lubuntu 10.04, so maybe this issue is specific to Lubuntu
> 12.04.

Now that's interesting! So the driver version is the same and the xorg.conf is the same but on one system, you see the error and on the other system you don't? That must be due to the different versions of xorg-server. If that's the case, you should go on the working system and incrementally update to a new xorg-server and report the first version where it breaks. Checking Xorg.0.log at every stage to make sure the xorg.conf is being obeyed is important too.

> Is it possible to make changes in your code so that an older version of
> xorg-macros can be used?

So far, I've only read that you had to install an older version of xorg-macros. I don't know how / if my code fails because of that version.

>     I do not want to say anything harsh regarding the rendering errors, but
> if this were a product to be sold to the general public, this will be a job
> security issue (i.e., employment termination) if this much amount of bugs
> went into the code (i.e., too many customer returns of the graphics card).
> Of course, I did not write the code, so I do not really have the right to
> criticize you too much.
> Please note that I live in what people call Silicon Valley (travelling right
> now), so losing a job and being unemployed for a long period of time is very
> common even for engineering people in the computer / electronics industry
> (i.e., myself).
> Corporations there literally throw engineers away all the time in the name
> of "cost cutting," but I will digress on that subject.

Which is better? Buggy EXA support or no EXA support? I've already told you how to prevent the buggy acceleration and the worst possible consequence of that is that your driver will be as slow as it was before I started working on it. Also please realize that I have no formal graphics training whatsoever. Most drivers other than intel / radeon / nouveau are developed by these types of people and I dare say they have worse EXA support.

>     How do you even debug x.org DDX device driver in Linux?

There's a proper way with ssh, but I do it in a modified printf way. If there's a variable you want to know about, write R128TRACE(("Some sentence: %d\n", var)); It has the same syntax as printf. These lines are printed to the log file which you can view while X is running. It will just be an ever-growing file that accumulates more lines as more debugging information is printed.

Created attachment 116895 [details]
Xorg.0.log with the likely fix patch applied device driver along with DRI and EXA activated xorg.conf (6)

Xorg.0.log with the syntax error corrected xorg.conf.

(In reply to Connor Behan from comment #40)

Hi Connor,

Actually, if I change the screen refresh rate from, say 75 Hz to 60 Hz, after the screen refresh rate changes in Lubuntu 12.04, the junk object shows up on the screen.
This is at 1280 X 1024.
Lubuntu 12.04 uses LXRandR to change the screen resolution (Preferences -> Monitor Settings).
This does not happen with Lubuntu 10.04 (Used the same code and xorg.conf).
I will investigate this issue further, but that is what I got for now.
I will likely open a new bug report for this specific issue.
    Ubuntu changed the location of xorg.conf starting in Ubuntu 10.10.
I am just stating this in case someone else is also trying to do the same thing I did (i.e., backport your device driver to older releases of Ubuntu since Canonical doesn't really update device drivers to fix bugs).
    The xorg-macros version issue makes it harder for people trying to backport it to Ubuntu 10.04 era Ubuntu.
Of course, it is not impossible if people followed the instructions I posted a couple of comments ago.
For the sake of backward compatibility, I personal prefer not using the latest thing (i.e., try to use an older xorg-macros if possible) unless it is absolutely necessary.
    Regarding the EXA support and rendering issues, I am sorry if what I wrote offended you, but the point I wanted to make was that if someone who worked at ATI Technologies wrote a Windows display device driver with the amount of 2D rendering issues I saw, that person will lose one's job pretty quickly since so many customers will return the graphics card to the retailer.
Of course, this kind of scenario will likely not happen since QA team will likely catch it before release (project schedule will be impacted).
I am just trying to improve the quality of Linux device drivers since it is still pretty bad overall even today.
Please understand that I am trying to help you improve the code you wrote so that EXA related rendering bugs are eventually eliminated, and I will no longer see junk on the screen.
My personal goal will be to get these issues resolved prior to Ubuntu 16.04 LTS release again since Canonical does not seem to fix device driver problems after the release.
It will be nice if someone else more knowledgeable about Linux programming than myself can develop a GUI-based x.org DDX device driver update utility so that non-technical people can install your updated device driver without having to go through the compilation steps I went through.
    Please note that I am not a CS (Computer Science) person, either.
However, when I was a kid, I did do some low level VGA programming where I was trying to develop a game in x86 assembly language.
I am really a hardware design person who happened to work on low level software projects when I feel like it.
I work on FPGA (Field Programmable Gate Array) based hardware primarily (Xilinx), although I am not trying to advertise myself for a job in that field anymore (As I have said previously, I do live in what people call Silicon Valley, and the way electronics / computer industry engineering people are treated in SV is definitely a factor. There are other reasons, but I do not wish to offend anyone, so I will not explain other reasons here. The media always make it sound like SV is such a rosy place, but that certainly isn't true for many, including me.).
This one happened to be something I wanted to work on during summer since I worked on a difficult FPGA design project for 9 months with someone else (we did not finish it, although we plan to resume the work on it in the future), and wanted to do something else for a change.
I happened to have hardware design background in PC interface design (PCI bus, some PCI Express interface), DMA engine design (I used it with the PCI interface core I developed.), and DRAM controller design (SDRAM, DDR3 SDRAM).
Again, I am not writing this stuff to brag about or advertise myself to get a job, but just want to mention it so that you have an idea where I am coming from.
In hardware design, engineers have to do fairly rigorous design verification, if it expects the hardware to function at all (FPGAs are somewhat forgiving since if the bug is only inside the chip, the internal logic can be changed fairly easily, but a standard cell ASIC (Application Specific Integrated Circuit) like Rage 128 is not forgiving at all. ATI Technologies appear to have spun Rage 128 at least 4 times according to their documentation. They appear to have had many months of schedule slippage due to buggy ASICs.).
So, from my background in digital logic design and verification, the amount of testing software people in Linux development do is shockingly short and light.
This is probably why I made the comments I made that you were not happy with.
Again, I did not mean to offend you, so please don't take it that way (I was actually afraid you will be offended with what I wrote, and it appears like it turned out like that.).
I am trying to help you out fix various device driver issues, in particular the EXA rendering, so that many people around the world can continue to use their old hardware with decent performance (Pentium 4 with 1 GB of RAM and Rage 128 Pro should be at least adequate for basic computer use even today, as long as a light weight Linux distribution like Lubuntu is used.).
I will post the various other issues I see with the current x.org DDX r128 device driver in another bug report, if you don't mind.
I will post a little more testing results with a few other monitors by tomorrow, and than you can submit a commit to update your device driver on freedesktop.org Git repository.

Regards,

Kevin Brace


> (In reply to Kevin Brace from comment #37)
> > (In reply to Connor Behan from comment #35)
> > Do you have any debug code to look into the hardware cursor address, and see
> > if it comes into conflict when the screen resolution changes?
> > It looks to me that is what is happening.
> 
> That can't be it. The card is only told what addresses to use when the
> server starts up. It allocates the cursor once and never again. The front /
> back / depth buffers that it allocates in front of it are also big enough to
> fit any mode that X will let you switch to later. So none of the addresses
> will change or be overwritten.
> 
> Answering these might be useful. You say the cursor gets corrupted when you
> go from 1280x1024 to 1024x768. Does this mean you start off with 1280x1024
> and switch to 1024x768 in mid-session using a randr client program? If so,
> do you still get the same error if you modify your xorg.conf to start off
> with 1024x768 resolution from the get-go? If so, see if the same thing still
> happens on a pre-randr version of the driver.
> 
> > Pretty much the instructions on how to compile and install is the same,
> > however, I believe the location of xorg.conf is going to be different in
> > Lubuntu 10.04 (it has to be located in /usr/lib/X11/xorg.conf.d).
> 
> I've never heard of an X version that didn't source /etc/X11/xorg.conf but
> if you think it's safer to move somewhere else, go for it.
> 
> > I do not recall seeing the corrupted junk on the screen when changing screen
> > resolution in Lubuntu 10.04, so maybe this issue is specific to Lubuntu
> > 12.04.
> 
> Now that's interesting! So the driver version is the same and the xorg.conf
> is the same but on one system, you see the error and on the other system you
> don't? That must be due to the different versions of xorg-server. If that's
> the case, you should go on the working system and incrementally update to a
> new xorg-server and report the first version where it breaks. Checking
> Xorg.0.log at every stage to make sure the xorg.conf is being obeyed is
> important too.
> 
> > Is it possible to make changes in your code so that an older version of
> > xorg-macros can be used?
> 
> So far, I've only read that you had to install an older version of
> xorg-macros. I don't know how / if my code fails because of that version.
> 
> >     I do not want to say anything harsh regarding the rendering errors, but
> > if this were a product to be sold to the general public, this will be a job
> > security issue (i.e., employment termination) if this much amount of bugs
> > went into the code (i.e., too many customer returns of the graphics card).
> > Of course, I did not write the code, so I do not really have the right to
> > criticize you too much.
> > Please note that I live in what people call Silicon Valley (travelling right
> > now), so losing a job and being unemployed for a long period of time is very
> > common even for engineering people in the computer / electronics industry
> > (i.e., myself).
> > Corporations there literally throw engineers away all the time in the name
> > of "cost cutting," but I will digress on that subject.
> 
> Which is better? Buggy EXA support or no EXA support? I've already told you
> how to prevent the buggy acceleration and the worst possible consequence of
> that is that your driver will be as slow as it was before I started working
> on it. Also please realize that I have no formal graphics training
> whatsoever. Most drivers other than intel / radeon / nouveau are developed
> by these types of people and I dare say they have worse EXA support.
> 
> >     How do you even debug x.org DDX device driver in Linux?
> 
> There's a proper way with ssh, but I do it in a modified printf way. If
> there's a variable you want to know about, write R128TRACE(("Some sentence:
> %d\n", var)); It has the same syntax as printf. These lines are printed to
> the log file which you can view while X is running. It will just be an
> ever-growing file that accumulates more lines as more debugging information
> is printed.

It's cool. I just wanted to mention that things being released before they are perfect is actually a good thing about open source. I already pushed the patch fixing the main bug here, so good luck with other testing you decide to do.

(In reply to Connor Behan from comment #43)

Hi Connor,

I have to disagree on the open source development model.
Things ought be to much more extensively tested before they are release whether or not it is commercial (i.e., closed source) or open source.
I do use Mozilla Firefox and OpenOffice.org on Windows because they are free and stable (at least much more stable than many Linux distributions).
They are fairly stable because someone tests them before release.
Except with Lenovo G570 laptop (has a Sandy Bridge-based Pentium), I still do not really use Linux too much since pretty much all of the FPGA design tools (Xilinx ISE and Vivado) work better in Windows (i.e., Installation is far easier and launch icons are installed automatically and correctly. Not always so in Linux world.), although many commercial Verilog simulators only support Linux these days (i.e., Synopsys VCS).
That being said, ModelSim works well on Windows, so I tend to stay with Windows.
The Lenovo G570 laptop is pretty nice as a Linux (Lubuntu 12.04) machine probably because Intel OSTC fixes many display device driver bugs prior to release.
That being said, microphone does not work with Ubuntu 12.04-based OSes, so I cannot use Skype, and that really is the only major bug I know (It was fixed in Lubuntu 14.04, but the fix has not been backported as far as I know.).
I have observed the same bug with Intel P67 chipset-based desktop mainboard, so I assume that this is common among certain generation Intel chipset audio.
    I did not originally wanted to do Linux related development work.
But due to Linux device drivers being so low in quality (except Intel OSTC stuff in the open source device driver category), I was "forced" to learn how to compile and install device drivers in Linux.
Obviously, I do not like being a guinea pig, but I feel like that is how Linux community really works, and as I understood of the comment you made.
This might be okay for developer type like myself (however, I am primarily a hardware developer, and it will always be that way), but I do not believe this is okay for ordinary users of computing devices (i.e., non-technical people who are the 97+% of computer users).
This type of reason is why people pay $400 USD more for a comparable hardware spec. Apple Mac over plethora of Windows PCs.
Except for Android, nobody considers Linux except for technical types.
If software installation was more automatic and device drivers were reliable, more people will consider non-Android Linux.
    Regarding the VESA DDC bug, I did notice that you upgraded your code base.

http://cgit.freedesktop.org/xorg/driver/xf86-video-r128/commit/?id=d6dd6c9ad5ba8e4950c9398d93298fea48745263

Thank you very much for including my name since this is the first time I got my name included for any Linux related fix.
I have been trying to fix Linux device driver issues for many years, and this is the first time it happened.
That being said, I believe I wrote something like I wanted to do a little more testing prior to you doing a new commit.
Unfortunately, your code related to VESA DDC is still far from perfect.
Late last night, I tested the patched version device driver on hand (I will switch to your new code base shortly.) with an old 21 inch CRT monitor called HP P1110 (It is basically a giant glass "rock." Extremely difficult to move due to its weight.).
The same exact "type" of problem manifested itself again.
This monitor is capable of 1600 X 1200 resolution.
Rage 128 family is also capable of 1600 X 1200 resolution.
Probably due to its age, the Xorg.0.log showed that the R128 was reporting VESA DDC error.
Because of this, your r128 x.org DDX device driver was not able to select a screen (the reason why I could not run X server prior to your fix), hence, X server refused to start again.
I suspected that maybe the monitor cable was bad, so I had to tilt the monitor in order to reach behind to attach the VGA cable.
I turned the monitor back on (It was not in a tilting position at this point.), and that is when it "smoked."
I did smell foul odor, so I assume that the monitor is now dead.
I did salvage the VGA cable I used with it, and tested with a different LCD monitor called Lenovo L171.
The Lubuntu 12.04 and 10.04 do boot with Lenovo L171 monitor, but the "stuck junk cursor" problem is present with Lubuntu 12.04.
The HP 21 inch monitor is 15 years old, and I got it for $70 in early 2000s, so I certainly do not blame you for it finally dying since I myself do not really want to use it (i.e., weight issue), and besides it was already sort of dying anyway.
    Basically, your code needs to be modified so that it can "tolerate" a VESA DDC error.
It is not written that way currently, and this should change.
Say VESA DDC error occurred, than you should select 640 X 480 and / or 800 X 600 screen resolution as a fall back.
Remember, VESA DDC was not even available until mid-'90s.
There are VGA monitors without VESA DDC.
Your code should be able to handle such monitors as well, although I may only own one such monitor (20+ year old 14 inch "Super VGA" monitor my friend was tossing out. I kept it since it still works, even though it is currently in storage. I doubt it even has VESA DDC.).
Besides this, people *DO* boot their computers without VGA monitor attached sometimes in desktop environment (i.e., Because they were lazy, they decided to attach the monitor later. I have done this. Most device driver can tolerate this in Windows.).
Based on what happened with HP P1110 monitor VESA DDC error, I am not too confident that X server will boot if the monitor is not attached during X server boot.
     I think this bug report is already getting very long, and except for VESA DDC error condition, X server will now start.
I think you can close this bug report as FIXED by referencing your latest commit I referenced earlier.
For the newer VESA DDC monitor detection error condition issue I have observed, I will file a new bug report.
I will add the list of monitors I was able to get the updated device driver working to this report sometime tomorrow.
For other bugs and performance issues I have observed with your device driver since I got it up and running with Lubuntu 12.04 and 10.04, I will file individual bug reports rather than putting all of them in one report.
I will likely file 3 to 4 reports in the next 2 week or so, so be ready.

Regards,

Kevin Brace


> It's cool. I just wanted to mention that things being released before they
> are perfect is actually a good thing about open source. I already pushed the
> patch fixing the main bug here, so good luck with other testing you decide
> to do.

Fixed by commit d6dd6c9ad5ba8e4950c9398d93298fea48745263. The remaining bug (aborting for non-DDC equipped monitors) might be on the X server side since r128 doesn't decide to terminate. All it does it return XF86OutputStatusDisconnected.