Puppy Linux Discussion Forum

[PaulBx1]

Guys, I'm running Puppy 4.1.2 on a Sony VGN-C140G laptop. It has this weird issue with rendering fonts:



Notice the third line from the bottom? If I scroll that line off the screen and back on, it is changed (usually improved). If I do that a couple times, it cleans up completely.

I have seen this in seamonkey and rxvt.

When I took a snapshot of this I was in mtpaint, of course. scrolling that same line on and off the screen did not change it, because by that point it was an image, of course.

Sometimes it gets so bad it is hard to read the text. It seems to come and go...

I tried changing fonts in Seamonkey, didn't help.

If anyone has an idea, I'd appreciate hearing it...

[Sit Heel Speak]

Retro or regular kernel?

[disciple]

Personally I suspect it's a problem with the video hardware or something, but I'm not an expert.

[PaulBx1]

It's the regular kernel, 2.6.25.16.

Yeah, it could always be hardware. I'm just wondering how to narrow this down, if there is a way.

[Sit Heel Speak]

At this juncture I'm a bit at sea, though not entirely.

Your complaint involves the same kernel, same XOrg, and same 945 video chipset as a losing battle I just fought over in another thread. I hope to soon have that machine in my physical possession and perhaps then can confidently render useful advice.

Until then, as a first wild stab: in Seamonkey, I would open an about:config window, filter on "layout", choose layout.css.dpi, and see if changing the value from -1 to 0 helps. My thinking is: this might fix it if the 945 uses some proprietary translation method of rendering its unusual 113 dpi screen resolution, because maybe the relatively newer 945's method of rendering to 113 dpi had not yet been accommodated-for in 412's relatively older XOrg. Therefore XOrg might be taking a bad algorithmic guess and so maybe SM is feeding output (through XOrg) to an erroneous screenres of some smaller dpi value than the unusual true one. If the by-XOrg-guessed-at resolution is lower than 96 then even if the 945 knows how to accommodate the bad (lower) dpi guess of an older XOrg the -1 setting would be throwing things off, since -1 forces SM to render at 96 dpi if 96 is higher than the by-XOrg-computed (i.e. "algorithmically guessed at") dpi value. Libfreetype/libxft is capable of compensating for a great variety of mismatching dpi value cases between app/xorg/adapter, but your system, it seems, is at times stepping a little beyond the limits of its known case universe. Perhaps the solution lies in adjusting ...and on and on...--If all this wild hypothesis is perchance the truth, e.g. if XOrg is wrongly seeing 75 dpi as the adapter's value, then changeing layout.css.dpi to 0 should fix it.

(heh...and disciple is expecting me, in another thread, to concisely explain...why...filesystem name encoding can be mistaken for document language encoding...on a wine system... maybe in a few months... )

I know a similar problem as that hypothesized above, afflicts some examples of the i810 video chipset and have seen similar, though not identical, oddities in SM text rendering on these.

Then, if 0 instead of -1 doesn't cure it, I'd try changing layout.css.dpi to the actual physical dpi of 113, and add the right DisplaySize and DPI lines e.g.

[PaulBx1]

Wow SHS!

It just occurred to me I don't even know if I'm using Xorg or Xvesa. How does one tell?

Here is my Xorg.0.log, for what it's worth:

[Sit Heel Speak]

[PaulBx1]

Ah, now I recall. I was trying arch linux and couldn't get xorg to work with that. I didn't have that problem with Puppy.

I found this item which may be of interest:
http://www.rev.net/~mike/sonyVGN-C140G_laptopFC6.html

His xorg.conf is here:
http://www.rev.net/~mike/xorg.conf

The most significant difference appears to be his use of the i810 driver, where I used the intel driver.

[PaulBx1]

Getting back to your earlier requests: