Font artifacts.

[HaikuBot]

Hello.

Today I went to my neighbor with Haiku for test. All work fine, but when we tried to set resolution 1680x1050, we saw some font artifacts. They are gone when resolution is 1280x1024 and lower. On all my home PCs I never seen this artifacts.

In ubuntu and WinXP all fine with 1680x1050.

Neighbor's PC have Athlon 3600+ 64 x2, 1GB RAM, integrated graphic card GeForce 6100 and Samsung 225BW monitor 22 Inch.

Here photos with font artifacts:

• ​One
• ​Two

[axeld]

First of all, please attach images rather than adding links.

However, the image quality is so bad, that I can't see any artifacts - I'm afraid you have to elaborate a bit :-)

[HaikuBot]

Ok, tomorrow I will make photos with better quality.

[HaikuBot]

Added photos with better quality. ​Here also video example.

[umccullough]

This is exactly what I have seen when trying to use the non-native resolution for a given LCD display (for example, using interpolation to see 1280x1204 on an LCD projector that only supports native 1024x768)

[umccullough]

To clarify, I'm not saying you've done something wrong, but perhaps the nvidia driver is trying to scale internally or something.

[umccullough]

Tentatively changing to nvidia driver (change it back if i'm wrong)

[umccullough]

And sorry to spam this ticket, but would subpixel rendering be involved here? Perhaps the subpixel rendering is enabled and the subpixels are backwards on that particular display?

[axeld]

I haven't seen the outcome of that yet, but I don't think it would look like that; it really looks like a scaling issue, and since the app_server doesn't do that itself, it can only be VESA or the nVidia driver which is responsible for this.

[HaikuBot]

Added logs.

[rudolfc]

Hi,

Thanks for the pictures and log. What I see here is a typical case of the screen not correctly phasing to the incoming pixel 'datastream' on a VGA connection. This can be if the number of pixels in a line is not like the monitor wants it. This happens more often on relative cheap VGA connected screens because the autosetting feature is not very good there. You can try to manually modify the monitor's phase setting (and the other related sync settings) to get a decent 1:1 pixel output.

If that is not possible then it's a good plan to try the exact modeline as reported in the driver log as being the native line:

I2C: specsEDID: timing.pixel_clock 146.250 Mhz I2C: specsEDID: timing.h_display 1680 I2C: specsEDID: timing.h_sync_start 1784 I2C: specsEDID: timing.h_sync_end 1960 I2C: specsEDID: timing.h_total 2240 I2C: specsEDID: timing.v_display 1050 I2C: specsEDID: timing.v_sync_start 1053 I2C: specsEDID: timing.v_sync_end 1059 I2C: specsEDID: timing.v_total 1089

if you want to test that please modify the modeline in a local copy of the driver source if needed.

Please keep me posted!

Bye!

Rudolf.

[rudolfc]

Hi again,

Could you give an update on how the current driver works? There have been improvements in pixelPLL programming, which might influence the picture quality.

If it's still not OK, please try this trick: keep the native resolution, but select a slightly higher refreshrate (65Hz, or 70Hz or so).

Does that solve the problem?

(try the 'auto adjust' function with the new refreshrate and new driver please).

Could you check the linux and windows refreshrates reported by the screen?

Thanks!

Rudolf.

[HaikuBot]

Hello.

Sorry for long respond. My neighbor buy new PC, so this ticket not actual. Please, close it.

[rudolfc]

I.m assuming it's fixed then.

Bye!

Rudolf.