[gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

When I was using an Nvidia video card, I noticed a strange sort of
fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
have the same problem.  Now I've switched to an ATI video card and
unfortunately I have the same problem with xf86-video-ati.  I tried to
enable the new modesetting radeon driver in the kernel to see if that
would help but it doesn't work with my HD4250 card yet.  Does anyone
know how to fix this?  Here's a photo of the effect around the mouse
cursor:

http://imageshack.us/photo/my-images/804/cursor.jpg

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[meino.cramer]

Grant <emailgrant@gmail.com> [11-07-10 01:42]:
> When I was using an Nvidia video card, I noticed a strange sort of
> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> have the same problem.  Now I've switched to an ATI video card and
> unfortunately I have the same problem with xf86-video-ati.  I tried to
> enable the new modesetting radeon driver in the kernel to see if that
> would help but it doesn't work with my HD4250 card yet.  Does anyone
> know how to fix this?  Here's a photo of the effect around the mouse
> cursor:
> 
> http://imageshack.us/photo/my-images/804/cursor.jpg
> 
> - Grant
> 

Hi Grant,

just a shot in the dark:
The image looks to me as thos would be an analog instead of
an digital problem.
May be both propietary drivers switch to the highest possible
data transfer rate and this triggers the problem.
To check, whether this may be the problem:
Instruct the driver to use either low resolution or low refresh 
rates. Check both.
If the problem changes signifiently: Change the cables.
May be only a pluf is not inserted correctly.
Addtionally you can move the cables arround to see whether
this will change the shadows around the cursor in any way...

Good luck! :)
Best regards
mcc

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> When I was using an Nvidia video card, I noticed a strange sort of
>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>> have the same problem.  Now I've switched to an ATI video card and
>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>> enable the new modesetting radeon driver in the kernel to see if that
>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>> know how to fix this?  Here's a photo of the effect around the mouse
>> cursor:
>>
>> http://imageshack.us/photo/my-images/804/cursor.jpg
>>
>> - Grant
>>
>
> Hi Grant,
>
> just a shot in the dark:
> The image looks to me as thos would be an analog instead of
> an digital problem.
> May be both propietary drivers switch to the highest possible
> data transfer rate and this triggers the problem.
> To check, whether this may be the problem:
> Instruct the driver to use either low resolution or low refresh
> rates. Check both.
> If the problem changes signifiently: Change the cables.
> May be only a pluf is not inserted correctly.
> Addtionally you can move the cables arround to see whether
> this will change the shadows around the cursor in any way...
>
> Good luck! :)
> Best regards
> mcc

Thanks for that.  I'm still working on it but adding radeon.audio=0 to
grub cleaned it up about 75%.

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>>> When I was using an Nvidia video card, I noticed a strange sort of
>>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>>> have the same problem.  Now I've switched to an ATI video card and
>>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>>> enable the new modesetting radeon driver in the kernel to see if that
>>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>>> know how to fix this?  Here's a photo of the effect around the mouse
>>> cursor:
>>>
>>> http://imageshack.us/photo/my-images/804/cursor.jpg
>>>
>>> - Grant
>>>
>>
>> Hi Grant,
>>
>> just a shot in the dark:
>> The image looks to me as thos would be an analog instead of
>> an digital problem.
>> May be both propietary drivers switch to the highest possible
>> data transfer rate and this triggers the problem.
>> To check, whether this may be the problem:
>> Instruct the driver to use either low resolution or low refresh
>> rates. Check both.
>> If the problem changes signifiently: Change the cables.
>> May be only a pluf is not inserted correctly.
>> Addtionally you can move the cables arround to see whether
>> this will change the shadows around the cursor in any way...
>>
>> Good luck! :)
>> Best regards
>> mcc
>
> Thanks for that.  I'm still working on it but adding radeon.audio=0 to
> grub cleaned it up about 75%.
>
> - Grant

It turns out the radeon.audio=0 setting disables HDMI data packets and
puts the HDMI port in DVI mode.  mcc, I'm starting to think you had it
pretty right on.  I've tried two different cables with the same result
but I'm thinking this may be some sort of electrical interference
issue.  I deal with stuff like that in audio.  There's a USB isolator
which cleans the sound way up when used with a USB sound card:

http://www.analog.com/en/interface/digital-isolators/adum4160/products/product.html

Now I wish there was something like that for HDMI.

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[meino.cramer]

Grant <emailgrant@gmail.com> [11-07-13 03:13]:
> >>> When I was using an Nvidia video card, I noticed a strange sort of
> >>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> >>> have the same problem.  Now I've switched to an ATI video card and
> >>> unfortunately I have the same problem with xf86-video-ati.  I tried to
> >>> enable the new modesetting radeon driver in the kernel to see if that
> >>> would help but it doesn't work with my HD4250 card yet.  Does anyone
> >>> know how to fix this?  Here's a photo of the effect around the mouse
> >>> cursor:
> >>>
> >>> http://imageshack.us/photo/my-images/804/cursor.jpg
> >>>
> >>> - Grant
> >>>
> >>
> >> Hi Grant,
> >>
> >> just a shot in the dark:
> >> The image looks to me as thos would be an analog instead of
> >> an digital problem.
> >> May be both propietary drivers switch to the highest possible
> >> data transfer rate and this triggers the problem.
> >> To check, whether this may be the problem:
> >> Instruct the driver to use either low resolution or low refresh
> >> rates. Check both.
> >> If the problem changes signifiently: Change the cables.
> >> May be only a pluf is not inserted correctly.
> >> Addtionally you can move the cables arround to see whether
> >> this will change the shadows around the cursor in any way...
> >>
> >> Good luck! :)
> >> Best regards
> >> mcc
> >
> > Thanks for that.  I'm still working on it but adding radeon.audio=0 to
> > grub cleaned it up about 75%.
> >
> > - Grant
> 
> It turns out the radeon.audio=0 setting disables HDMI data packets and
> puts the HDMI port in DVI mode.  mcc, I'm starting to think you had it
> pretty right on.  I've tried two different cables with the same result
> but I'm thinking this may be some sort of electrical interference
> issue.  I deal with stuff like that in audio.  There's a USB isolator
> which cleans the sound way up when used with a USB sound card:
> 
> http://www.analog.com/en/interface/digital-isolators/adum4160/products/product.html
> 
> Now I wish there was something like that for HDMI.
> 
> - Grant
> 

Hi Grant,

another shot into an even much deeper dark .... ;)

May be you have a problem here, which it is called "Brummschleife"
in german...sorry dont know the English equivalent...may be something
like "buzzing loop"...but this looks more like a strange translation 
made by google than by any other, human being ;)
Anyway....

A "Brummschleife" happens when doing something like this:

              +----+                          +-----------+
--------------+    |-(1)----------------------+ monitor or|-------------
mains         | PC |-(2)----------------------| amplifier |        mains         
--------------+    |    (audio/USB/video or   + or.....   |-------------
-+------------+----+     another low voltage  +-----------+-----------+-            
 |                       thingy)                                      |            
 (3)                                                                (4)
 |                                                                    |            
 _                                                                    _            
 ground                                                               ground       


 Normally all protective earth's connection should end in ONE point: A
 copper rod or someting like this.
 BUT often the wires between them are too long or there are two or
 even more end points. Result: HF from near by broadcast stations,
 60Hz mains frequency, ham radio station, microwave ovens and anything
 which can emit energy, pushes protective earth to another electrical
 potential than 0V.
 Since both, PC and -- in your case -- the monitor are using
 protective earth, they may be put on "another", may be even
 varying (over time) electrical potentials. Since they are connected 
 via a two-wire connection WITHOUT protective earth (no, the shielding 
 is not for that purpose) the difference in the potential earth put 
 both ends to different electrical reference points.
 This way you get an amplitude modulation of the signal between both
 endpoint. In case of 60HZ you will hear a "Brummschleife" sound on
 audio connection (a buzzing sound), in case of frequencies near 
 those of the video signal you will get "ghosts" in the monitor picture.

 Now, how to avoid that.
 Hit the one who have made the protective earth connection in your
 house.
 While you are searching for that person, you can try the following:
 Put all mains connectors of you PC rig into ONE wall connector
 with something like this (ok I miss some words here again and 
 since a picture says more than even thousands of /missing/ words
 here comes an image of what I mean:):
http://www.reichelt.de/Steckdosenleisten-ohne-Schalter/6-FACH-DOSE-WS-5/index.html?;ACTION=3;LA=2;ARTICLE=108651;GROUPID=4281;SID=11Thz@On8AAAIAABaBBrE9f5418078c2ea9fe6608e9765d978595

This way, all protective earth ends up in the same contact. No
differences in the electricla potential of the protective earth
anymore.

Why does the those USB-isolatore-like cables help here?

These small air core transformers (or in other words: There is
no core at all... ;) ) do a (german, sorry...)
"Gleichtaktunterdrueckung" which means, that any
potential difference (which is: the signal itsself) between
wire (1) and wire (2) is transmitted, and any modulating 
difference of electrical potential between (3) and (4),
influencing (1) and (2) at the same time the same way will
be suppressed by the transformers.


Hopefully the theorectical aspect of this will not surpress
the practical success here ;)

Good luck!
Best regards,
mcc

[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Nikos Chantziaras]

On 07/10/2011 02:21 AM, Grant wrote:
> When I was using an Nvidia video card, I noticed a strange sort of
> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> have the same problem.  Now I've switched to an ATI video card and
> unfortunately I have the same problem with xf86-video-ati.  I tried to
> enable the new modesetting radeon driver in the kernel to see if that
> would help but it doesn't work with my HD4250 card yet.

It should work.  But you need firmware that is not included in the 
kernel.  You need to install the x11-drivers/radeon-ucode package, and 
then build a kernel that includes the appropriate firmware.  Which 
firmware file (one of the *.bin files in /lib/firmware/radeon) is needed 
should be printed during boot; at the moment the kernel hangs, it should 
print which firmware file it was trying to load.

On my HD4870, I configured it like so:

In "Device Drivers -> Generic Driver Options", I've set:

(radeon/R700_rlc.bin) External firmware blobs to build into the kernel 
binary
(/lib/firmware) Firmware blobs root directory

Then rebuild and install the kernel.  Before you reboot, make sure you 
have built media-libs/mesa with the "gallium" USE flag set, and do an 
"eselect mesa set r600 gallium".  Make sure you don't have disabled KMS 
in the kernel command line or module options ("radeon.modeset=0" 
disables KMS).  After you reboot, you should have KMS + Gallium3D working.

[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Nikos Chantziaras]

On 07/13/2011 01:33 AM, Grant wrote:
>>>> When I was using an Nvidia video card, I noticed a strange sort of
>>>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>>>> have the same problem.  Now I've switched to an ATI video card and
>>>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>>>> enable the new modesetting radeon driver in the kernel to see if that
>>>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>>>> know how to fix this?  Here's a photo of the effect around the mouse
>>>> cursor:
>>>>
>>>> http://imageshack.us/photo/my-images/804/cursor.jpg
>>>>
>>>> - Grant
>>>>
>>>
>>> Hi Grant,
>>>
>>> just a shot in the dark:
>>> The image looks to me as thos would be an analog instead of
>>> an digital problem.
>>> May be both propietary drivers switch to the highest possible
>>> data transfer rate and this triggers the problem.
>>> To check, whether this may be the problem:
>>> Instruct the driver to use either low resolution or low refresh
>>> rates. Check both.
>>> If the problem changes signifiently: Change the cables.
>>> May be only a pluf is not inserted correctly.
>>> Addtionally you can move the cables arround to see whether
>>> this will change the shadows around the cursor in any way...
>>>
>>> Good luck! :)
>>> Best regards
>>> mcc
>>
>> Thanks for that.  I'm still working on it but adding radeon.audio=0 to
>> grub cleaned it up about 75%.
>>
>> - Grant
>
> It turns out the radeon.audio=0 setting disables HDMI data packets and
> puts the HDMI port in DVI mode.  mcc, I'm starting to think you had it
> pretty right on.  I've tried two different cables with the same result
> but I'm thinking this may be some sort of electrical interference
> issue.

HDMI is digital, so there can be no interference.  This looks more like 
a driver bug.

Btw, why are you connecting to your monitor with HDMI?  For computer 
monitors, you use the DVI port, not HDMI.  HDMI is for TVs.  Unless of 
course your monitor lacks a digital DVI port (DVI-I or DVI-D).  If it 
only has a DVI-A port, only then is HDMI the better solution.

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1803 bytes --]

On Wednesday 13 Jul 2011 08:13:27 Nikos Chantziaras wrote:
> On 07/10/2011 02:21 AM, Grant wrote:
> > When I was using an Nvidia video card, I noticed a strange sort of
> > fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> > have the same problem.  Now I've switched to an ATI video card and
> > unfortunately I have the same problem with xf86-video-ati.  I tried to
> > enable the new modesetting radeon driver in the kernel to see if that
> > would help but it doesn't work with my HD4250 card yet.
> 
> It should work.  But you need firmware that is not included in the
> kernel.  You need to install the x11-drivers/radeon-ucode package, and
> then build a kernel that includes the appropriate firmware.  Which
> firmware file (one of the *.bin files in /lib/firmware/radeon) is needed
> should be printed during boot; at the moment the kernel hangs, it should
> print which firmware file it was trying to load.
> 
> On my HD4870, I configured it like so:
> 
> In "Device Drivers -> Generic Driver Options", I've set:
> 
> (radeon/R700_rlc.bin) External firmware blobs to build into the kernel
> binary
> (/lib/firmware) Firmware blobs root directory
> 
> Then rebuild and install the kernel.  Before you reboot, make sure you
> have built media-libs/mesa with the "gallium" USE flag set, and do an
> "eselect mesa set r600 gallium".  Make sure you don't have disabled KMS
> in the kernel command line or module options ("radeon.modeset=0"
> disables KMS).  After you reboot, you should have KMS + Gallium3D working.

I think the OP's card needs R600_rcl.bin as I've suggested in a previous 
message.

Is the gallium stable now?  I found it was locking up a kde desktop with 
effects enabled and set it back to classic.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Nikos Chantziaras]

On 07/13/2011 03:25 PM, Mick wrote:
> [...]
> Is the [r600] gallium stable now?  I found it was locking up a kde desktop with
> effects enabled and set it back to classic.

It's been made the default driver in Mesa now.  So I guess that means 
it's considered stable.  But for me, both classic and gallium can hang 
the machine.  At least with Gallium I know how to fix it though:

   Section "Device"
         Identifier "HD4870"
         Driver "radeon"
         Option "EnablePageFlip" "FALSE"
   EndSection

in an xorg.conf.d file.

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Roger Mason]

meino.cramer@gmx.de writes:

>
> Hi Grant,
>
> another shot into an even much deeper dark .... ;)
>
> May be you have a problem here, which it is called "Brummschleife"
> in german...sorry dont know the English equivalent...may be something
> like "buzzing loop"...but this looks more like a strange translation 
> made by google than by any other, human being ;)
> Anyway....

What you are describing that is, I think, called a "ground loop" in
English.

Cheers,
Roger

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[meino.cramer]

Roger Mason <rmason@mun.ca> [11-07-13 18:12]:
> meino.cramer@gmx.de writes:
> 
> >
> > Hi Grant,
> >
> > another shot into an even much deeper dark .... ;)
> >
> > May be you have a problem here, which it is called "Brummschleife"
> > in german...sorry dont know the English equivalent...may be something
> > like "buzzing loop"...but this looks more like a strange translation 
> > made by google than by any other, human being ;)
> > Anyway....
> 
> What you are describing that is, I think, called a "ground loop" in
> English.
> 
> Cheers,
> Roger
> 

Hi Roger,

oh, thanks! One gap filled !!! ;)))

Best regards,
mcc

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 712 bytes --]

On Wednesday 13 Jul 2011 15:42:02 Nikos Chantziaras wrote:
> On 07/13/2011 03:25 PM, Mick wrote:
> > [...]
> > Is the [r600] gallium stable now?  I found it was locking up a kde
> > desktop with effects enabled and set it back to classic.
> 
> It's been made the default driver in Mesa now.  So I guess that means
> it's considered stable.  But for me, both classic and gallium can hang
> the machine.  At least with Gallium I know how to fix it though:
> 
>    Section "Device"
>          Identifier "HD4870"
>          Driver "radeon"
>          Option "EnablePageFlip" "FALSE"
>    EndSection
> 
> in an xorg.conf.d file.

Great!  Thanks for the hint, I'll try it out.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> >>> When I was using an Nvidia video card, I noticed a strange sort of
>> >>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>> >>> have the same problem.  Now I've switched to an ATI video card and
>> >>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>> >>> enable the new modesetting radeon driver in the kernel to see if that
>> >>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>> >>> know how to fix this?  Here's a photo of the effect around the mouse
>> >>> cursor:
>> >>>
>> >>> http://imageshack.us/photo/my-images/804/cursor.jpg
>> >>>
>> >>> - Grant

>> >> The image looks to me as thos would be an analog instead of
>> >> an digital problem.

>  Put all mains connectors of you PC rig into ONE wall connector
>  with something like this (ok I miss some words here again and
>  since a picture says more than even thousands of /missing/ words
>  here comes an image of what I mean:):
> http://www.reichelt.de/Steckdosenleisten-ohne-Schalter/6-FACH-DOSE-WS-5/index.html?;ACTION=3;LA=2;ARTICLE=108651;GROUPID=4281;SID=11Thz@On8AAAIAABaBBrE9f5418078c2ea9fe6608e9765d978595

Thank you for taking the time to explain.  So I'm sure I understand
what it is I should try, I should connect my computer's power cable
and monitor's power cable to a power strip and plug that power strip
into an outlet?

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> When I was using an Nvidia video card, I noticed a strange sort of
>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>> have the same problem.  Now I've switched to an ATI video card and
>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>> enable the new modesetting radeon driver in the kernel to see if that
>> would help but it doesn't work with my HD4250 card yet.
>
> It should work.  But you need firmware that is not included in the kernel.
>  You need to install the x11-drivers/radeon-ucode package, and then build a
> kernel that includes the appropriate firmware.  Which firmware file (one of
> the *.bin files in /lib/firmware/radeon) is needed should be printed during
> boot; at the moment the kernel hangs, it should print which firmware file it
> was trying to load.
>
> On my HD4870, I configured it like so:
>
> In "Device Drivers -> Generic Driver Options", I've set:
>
> (radeon/R700_rlc.bin) External firmware blobs to build into the kernel
> binary
> (/lib/firmware) Firmware blobs root directory

You're right.  That fixed the stall during kernel load and now KMS works fine.

> Then rebuild and install the kernel.  Before you reboot, make sure you have
> built media-libs/mesa with the "gallium" USE flag set, and do an "eselect
> mesa set r600 gallium".  Make sure you don't have disabled KMS in the kernel
> command line or module options ("radeon.modeset=0" disables KMS).  After you
> reboot, you should have KMS + Gallium3D working.

I've eselected to gallium but is there any benefit if I don't use 3D at all?

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>>>>> When I was using an Nvidia video card, I noticed a strange sort of
>>>>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>>>>> have the same problem.  Now I've switched to an ATI video card and
>>>>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>>>>> enable the new modesetting radeon driver in the kernel to see if that
>>>>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>>>>> know how to fix this?  Here's a photo of the effect around the mouse
>>>>> cursor:
>>>>>
>>>>> http://imageshack.us/photo/my-images/804/cursor.jpg
>>>>>
>>>>> - Grant
>>>>>
>>>>
>>>> Hi Grant,
>>>>
>>>> just a shot in the dark:
>>>> The image looks to me as thos would be an analog instead of
>>>> an digital problem.
>>>> May be both propietary drivers switch to the highest possible
>>>> data transfer rate and this triggers the problem.
>>>> To check, whether this may be the problem:
>>>> Instruct the driver to use either low resolution or low refresh
>>>> rates. Check both.
>>>> If the problem changes signifiently: Change the cables.
>>>> May be only a pluf is not inserted correctly.
>>>> Addtionally you can move the cables arround to see whether
>>>> this will change the shadows around the cursor in any way...
>>>>
>>>> Good luck! :)
>>>> Best regards
>>>> mcc
>>>
>>> Thanks for that.  I'm still working on it but adding radeon.audio=0 to
>>> grub cleaned it up about 75%.
>>>
>>> - Grant
>>
>> It turns out the radeon.audio=0 setting disables HDMI data packets and
>> puts the HDMI port in DVI mode.  mcc, I'm starting to think you had it
>> pretty right on.  I've tried two different cables with the same result
>> but I'm thinking this may be some sort of electrical interference
>> issue.
>
> HDMI is digital, so there can be no interference.  This looks more like a
> driver bug.

I tried the latest git-sources-3.0 kernel with the same results.

> Btw, why are you connecting to your monitor with HDMI?  For computer
> monitors, you use the DVI port, not HDMI.  HDMI is for TVs.  Unless of
> course your monitor lacks a digital DVI port (DVI-I or DVI-D).  If it only
> has a DVI-A port, only then is HDMI the better solution.

The monitor is actually a 47" LG HDTV.  This is an HTPC.

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[meino.cramer]

Grant <emailgrant@gmail.com> [11-07-13 19:20]:
> >> >>> When I was using an Nvidia video card, I noticed a strange sort of
> >> >>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
> >> >>> have the same problem.  Now I've switched to an ATI video card and
> >> >>> unfortunately I have the same problem with xf86-video-ati.  I tried to
> >> >>> enable the new modesetting radeon driver in the kernel to see if that
> >> >>> would help but it doesn't work with my HD4250 card yet.  Does anyone
> >> >>> know how to fix this?  Here's a photo of the effect around the mouse
> >> >>> cursor:
> >> >>>
> >> >>> http://imageshack.us/photo/my-images/804/cursor.jpg
> >> >>>
> >> >>> - Grant
> 
> >> >> The image looks to me as thos would be an analog instead of
> >> >> an digital problem.
> 
> >  Put all mains connectors of you PC rig into ONE wall connector
> >  with something like this (ok I miss some words here again and
> >  since a picture says more than even thousands of /missing/ words
> >  here comes an image of what I mean:):
> > http://www.reichelt.de/Steckdosenleisten-ohne-Schalter/6-FACH-DOSE-WS-5/index.html?;ACTION=3;LA=2;ARTICLE=108651;GROUPID=4281;SID=11Thz@On8AAAIAABaBBrE9f5418078c2ea9fe6608e9765d978595
> 
> Thank you for taking the time to explain.  So I'm sure I understand
> what it is I should try, I should connect my computer's power cable
> and monitor's power cable to a power strip and plug that power strip
> into an outlet?
> 
> - Grant
> 

Yepp! 100% correct! :)

Good luck! :))

Best regards,
mcc

[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Nikos Chantziaras]

On 07/13/2011 08:23 PM, Grant wrote:
>[...]
> I've eselected to gallium but is there any benefit if I don't use 3D at all?

You don't know what uses OpenGL and what not (OpenGL is uses for much 
more than just "3D").  Also, you're not paying for it so why not use it? 
  ;-)

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> >> >>> When I was using an Nvidia video card, I noticed a strange sort of
>> >> >>> fuzzy edge effect if I used nvidia-drivers.  xf86-video-nouveau didn't
>> >> >>> have the same problem.  Now I've switched to an ATI video card and
>> >> >>> unfortunately I have the same problem with xf86-video-ati.  I tried to
>> >> >>> enable the new modesetting radeon driver in the kernel to see if that
>> >> >>> would help but it doesn't work with my HD4250 card yet.  Does anyone
>> >> >>> know how to fix this?  Here's a photo of the effect around the mouse
>> >> >>> cursor:
>> >> >>>
>> >> >>> http://imageshack.us/photo/my-images/804/cursor.jpg
>> >> >>>
>> >> >>> - Grant
>>
>> >> >> The image looks to me as thos would be an analog instead of
>> >> >> an digital problem.
>>
>> >  Put all mains connectors of you PC rig into ONE wall connector
>> >  with something like this (ok I miss some words here again and
>> >  since a picture says more than even thousands of /missing/ words
>> >  here comes an image of what I mean:):
>> > http://www.reichelt.de/Steckdosenleisten-ohne-Schalter/6-FACH-DOSE-WS-5/index.html?;ACTION=3;LA=2;ARTICLE=108651;GROUPID=4281;SID=11Thz@On8AAAIAABaBBrE9f5418078c2ea9fe6608e9765d978595
>>
>> Thank you for taking the time to explain.  So I'm sure I understand
>> what it is I should try, I should connect my computer's power cable
>> and monitor's power cable to a power strip and plug that power strip
>> into an outlet?
>>
>> - Grant
>>
>
> Yepp! 100% correct! :)
>
> Good luck! :))
>
> Best regards,
> mcc

I gave it a try but there was no change.  I tried plugging the TV and
computer into a power strip and also into an isolation transformer.
Any other ideas?

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Michael Mol]

On Thu, Jul 14, 2011 at 3:44 PM, Grant <emailgrant@gmail.com> wrote:
> I gave it a try but there was no change.  I tried plugging the TV and
> computer into a power strip and also into an isolation transformer.
> Any other ideas?

Late to the party, but what kind of display? What connection are you
using to get from the card to the display? (i.e. I've got an LCD TV
which takes DVI, HDMI or VGA. I've got a few CRTs which only VGA...)


-- 
:wq

[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Nikos Chantziaras]

On 07/14/2011 10:44 PM, Grant wrote:
>
> I gave it a try but there was no change.  I tried plugging the TV and
> computer into a power strip and also into an isolation transformer.
> Any other ideas?

I still think it's a driver problem.  Again: it's *physically* 
impossible to have these problems with the HDMI signal.  At most you get 
"digital noise", which means some pixels get stuck or are missing.  But 
not what you get; that's just something that can't be explained.

I think it's worth reporting this as a bug upstream 
(http://bugs.freedesktop.org).

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> I gave it a try but there was no change.  I tried plugging the TV and
>> computer into a power strip and also into an isolation transformer.
>> Any other ideas?
>
> Late to the party, but what kind of display? What connection are you
> using to get from the card to the display? (i.e. I've got an LCD TV
> which takes DVI, HDMI or VGA. I've got a few CRTs which only VGA...)

It's a 47" LG LED HDTV connected via HDMI.

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> I gave it a try but there was no change.  I tried plugging the TV and
>> computer into a power strip and also into an isolation transformer.
>> Any other ideas?
>
> I still think it's a driver problem.  Again: it's *physically* impossible to
> have these problems with the HDMI signal.  At most you get "digital noise",
> which means some pixels get stuck or are missing.  But not what you get;
> that's just something that can't be explained.
>
> I think it's worth reporting this as a bug upstream
> (http://bugs.freedesktop.org).

I've been working with a couple of devs:

https://bugs.freedesktop.org/show_bug.cgi?id=39120

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1336 bytes --]

On Wednesday 13 Jul 2011 15:42:02 Nikos Chantziaras wrote:
> On 07/13/2011 03:25 PM, Mick wrote:
> > [...]
> > Is the [r600] gallium stable now?  I found it was locking up a kde
> > desktop with effects enabled and set it back to classic.
> 
> It's been made the default driver in Mesa now.  So I guess that means
> it's considered stable.  But for me, both classic and gallium can hang
> the machine.  At least with Gallium I know how to fix it though:
> 
>    Section "Device"
>          Identifier "HD4870"
>          Driver "radeon"
>          Option "EnablePageFlip" "FALSE"
>    EndSection
> 
> in an xorg.conf.d file.

Unfortunately it doesn't help.  If I enable compositing in KDE the screen 
locks up (with horizontal artifacts/tearing) and I get this in dmesg:

[drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[drm:r100_cs_track_check] *ERROR* [drm] No buffer for z buffer !
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

Google mentions a bug in mesa.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> I gave it a try but there was no change.  I tried plugging the TV and
>> computer into a power strip and also into an isolation transformer.
>> Any other ideas?
>
> I still think it's a driver problem.  Again: it's *physically* impossible to
> have these problems with the HDMI signal.  At most you get "digital noise",
> which means some pixels get stuck or are missing.  But not what you get;
> that's just something that can't be explained.

I was thinking about this.  The digital HDMI signal must be converted
into an analog signal at some point if it's being represented as light
on a TV screen.  Electrical interference generated by the computer and
traveling up the HDMI wire should have its chance to affect things
(i.e. create weird shadows) at that point, right?

- Grant

[gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Nikos Chantziaras]

On 07/17/2011 07:22 PM, Grant wrote:
>>> I gave it a try but there was no change.  I tried plugging the TV and
>>> computer into a power strip and also into an isolation transformer.
>>> Any other ideas?
>>
>> I still think it's a driver problem.  Again: it's *physically* impossible to
>> have these problems with the HDMI signal.  At most you get "digital noise",
>> which means some pixels get stuck or are missing.  But not what you get;
>> that's just something that can't be explained.
>
> I was thinking about this.  The digital HDMI signal must be converted
> into an analog signal at some point if it's being represented as light
> on a TV screen.  Electrical interference generated by the computer and
> traveling up the HDMI wire should have its chance to affect things
> (i.e. create weird shadows) at that point, right?

Not with DFPs.  Those work digital even internally.  I assume of course 
that his HDMI TV *is* a DFP.

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>>>> I gave it a try but there was no change.  I tried plugging the TV and
>>>> computer into a power strip and also into an isolation transformer.
>>>> Any other ideas?
>>>
>>> I still think it's a driver problem.  Again: it's *physically* impossible
>>> to
>>> have these problems with the HDMI signal.  At most you get "digital
>>> noise",
>>> which means some pixels get stuck or are missing.  But not what you get;
>>> that's just something that can't be explained.
>>
>> I was thinking about this.  The digital HDMI signal must be converted
>> into an analog signal at some point if it's being represented as light
>> on a TV screen.  Electrical interference generated by the computer and
>> traveling up the HDMI wire should have its chance to affect things
>> (i.e. create weird shadows) at that point, right?
>
> Not with DFPs.  Those work digital even internally.  I assume of course that
> his HDMI TV *is* a DFP.

But at some point the 1s and 0s must be converted to some sort of an
analog signal if only right behind the diode.  A diode must be
presented with a signal in some sort of analog form in order to
illuminate, right?  Digital is just a figment of our imagination after
all.

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Michael Mol]

On Sun, Jul 17, 2011 at 12:54 PM, Grant <emailgrant@gmail.com> wrote:
>>> I was thinking about this.  The digital HDMI signal must be converted
>>> into an analog signal at some point if it's being represented as light
>>> on a TV screen.  Electrical interference generated by the computer and
>>> traveling up the HDMI wire should have its chance to affect things
>>> (i.e. create weird shadows) at that point, right?
>>
>> Not with DFPs.  Those work digital even internally.  I assume of course that
>> his HDMI TV *is* a DFP.
>
> But at some point the 1s and 0s must be converted to some sort of an
> analog signal if only right behind the diode.  A diode must be
> presented with a signal in some sort of analog form in order to
> illuminate, right?  Digital is just a figment of our imagination after
> all.

Sure, but that couldn't introduce ghosting as shown in the picture.
Ghosting represents the image being offset in its intended raster
coordinates. By the time a diode is turned on or off, the decision if
which diode a signal goes to has already been made.

-- 
:wq

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>>>> I was thinking about this.  The digital HDMI signal must be converted
>>>> into an analog signal at some point if it's being represented as light
>>>> on a TV screen.  Electrical interference generated by the computer and
>>>> traveling up the HDMI wire should have its chance to affect things
>>>> (i.e. create weird shadows) at that point, right?
>>>
>>> Not with DFPs.  Those work digital even internally.  I assume of course that
>>> his HDMI TV *is* a DFP.
>>
>> But at some point the 1s and 0s must be converted to some sort of an
>> analog signal if only right behind the diode.  A diode must be
>> presented with a signal in some sort of analog form in order to
>> illuminate, right?  Digital is just a figment of our imagination after
>> all.
>
> Sure, but that couldn't introduce ghosting as shown in the picture.
> Ghosting represents the image being offset in its intended raster
> coordinates. By the time a diode is turned on or off, the decision if
> which diode a signal goes to has already been made.

True, but *is* that D/A conversion made right behind each diode?

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Stroller]

On 17 July 2011, at 17:54, Grant wrote:
> ...
> But at some point the 1s and 0s must be converted to some sort of an
> analog signal if only right behind the diode.  A diode must be
> presented with a signal in some sort of analog form in order to
> illuminate, right?  Digital is just a figment of our imagination after
> all.

The pixel is either on or off. There's no way to make half of the adjacent pixel on (and the other half of that pixel off).

Having said that, you may be on the right track. I hadn't looked at your photo before, so sorry for that, but it indeed looks like your telly may be doing some scaling on the image.

Check for overscan / underscan settings in the TV's menus and on the remote. The button for overscan may not be at all obvious on the remote from the icon that labels it - if you can't find a button on the remote that resolves this issue, or a overscan setting in the TV's menus then check the manual.

Overscan would cause this symptom, and it is such a common feature, that IMO you shouldn't pst back here again until you've identified it on your TV and checked it.

Stroller.

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> ...
>> But at some point the 1s and 0s must be converted to some sort of an
>> analog signal if only right behind the diode.  A diode must be
>> presented with a signal in some sort of analog form in order to
>> illuminate, right?  Digital is just a figment of our imagination after
>> all.
>
> The pixel is either on or off. There's no way to make half of the adjacent pixel on (and the other half of that pixel off).

Well, couldn't the digital information for a particular pixel mean
blue, and the D/A mechanism attempts to create an analog signal that
the diode would interpret as blue, but the D/A converter or the analog
signal or the analog diode is affected by electric interference (which
traveled from the computer to the TV along the HDMI cable) and the
diode illuminates light blue instead of blue?

> Having said that, you may be on the right track. I hadn't looked at your photo before, so sorry for that, but it indeed looks like your telly may be doing some scaling on the image.
>
> Check for overscan / underscan settings in the TV's menus and on the remote. The button for overscan may not be at all obvious on the remote from the icon that labels it - if you can't find a button on the remote that resolves this issue, or a overscan setting in the TV's menus then check the manual.
>
> Overscan would cause this symptom, and it is such a common feature, that IMO you shouldn't pst back here again until you've identified it on your TV and checked it.

You may be right about this.  I can select the following aspect ratios
on my TV's menu:

16:9 (this causes all 4 edges of the screen to be cut off)
Just Scan (this is what I use and it fits perfectly on the screen)
Set By Program (same as 16:9)
4:3 (same as 16:9 except with black boxes on the left and right)
Zoom (same as 16:9 except more of the image is cut off)
Cinema Zoom 1 (same as Zoom except nothing is cut off from the top of the image)

I set 1920x1080 in xorg.conf but I just tried defining no resolution
at all and it seems to have been set anyway:

(II) RADEON(0): Output HDMI-0 using initial mode 1920x1080

The TV is an LG 47LH90 and and it is said to do 1080p.  I looked for
ghosting in 16:9 mode instead of Just Scan mode and strangely the
shadows are there, but they're oriented top and bottom instead of left
and right.  I can take another photo if anyone would like to see.

Why do I need to select Just Scan in order to prevent all 4 edges of
the screen from being cut off?

- Grant

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>>> But at some point the 1s and 0s must be converted to some sort of an
>>> analog signal if only right behind the diode.  A diode must be
>>> presented with a signal in some sort of analog form in order to
>>> illuminate, right?  Digital is just a figment of our imagination after
>>> all.
>>
>> The pixel is either on or off. There's no way to make half of the adjacent pixel on (and the other half of that pixel off).
>
> Well, couldn't the digital information for a particular pixel mean
> blue, and the D/A mechanism attempts to create an analog signal that
> the diode would interpret as blue, but the D/A converter or the analog
> signal or the analog diode is affected by electric interference (which
> traveled from the computer to the TV along the HDMI cable) and the
> diode illuminates light blue instead of blue?
>
>> Having said that, you may be on the right track. I hadn't looked at your photo before, so sorry for that, but it indeed looks like your telly may be doing some scaling on the image.
>>
>> Check for overscan / underscan settings in the TV's menus and on the remote. The button for overscan may not be at all obvious on the remote from the icon that labels it - if you can't find a button on the remote that resolves this issue, or a overscan setting in the TV's menus then check the manual.
>>
>> Overscan would cause this symptom, and it is such a common feature, that IMO you shouldn't pst back here again until you've identified it on your TV and checked it.
>
> You may be right about this.  I can select the following aspect ratios
> on my TV's menu:
>
> 16:9 (this causes all 4 edges of the screen to be cut off)
> Just Scan (this is what I use and it fits perfectly on the screen)
> Set By Program (same as 16:9)
> 4:3 (same as 16:9 except with black boxes on the left and right)
> Zoom (same as 16:9 except more of the image is cut off)
> Cinema Zoom 1 (same as Zoom except nothing is cut off from the top of the image)
>
> I set 1920x1080 in xorg.conf but I just tried defining no resolution
> at all and it seems to have been set anyway:
>
> (II) RADEON(0): Output HDMI-0 using initial mode 1920x1080
>
> The TV is an LG 47LH90 and and it is said to do 1080p.  I looked for
> ghosting in 16:9 mode instead of Just Scan mode and strangely the
> shadows are there, but they're oriented top and bottom instead of left
> and right.  I can take another photo if anyone would like to see.
>
> Why do I need to select Just Scan in order to prevent all 4 edges of
> the screen from being cut off?
>
> - Grant

BTW I think you're on to something Stroller because the overall
picture is definitely improved in 16:9 mode compared to Just Scan
mode.  I just need to figure out how to prevent the edges of the
screen from being cut off.

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Volker Armin Hemmann]

On Sunday 17 July 2011 09:54:33 Grant wrote:
> >>>> I gave it a try but there was no change.  I tried plugging the TV
> >>>> and
> >>>> computer into a power strip and also into an isolation
> >>>> transformer.
> >>>> Any other ideas?
> >>> 
> >>> I still think it's a driver problem.  Again: it's *physically*
> >>> impossible to
> >>> have these problems with the HDMI signal.  At most you get "digital
> >>> noise",
> >>> which means some pixels get stuck or are missing.  But not what you
> >>> get; that's just something that can't be explained.
> >> 
> >> I was thinking about this.  The digital HDMI signal must be converted
> >> into an analog signal at some point if it's being represented as light
> >> on a TV screen.  Electrical interference generated by the computer and
> >> traveling up the HDMI wire should have its chance to affect things
> >> (i.e. create weird shadows) at that point, right?
> > 
> > Not with DFPs.  Those work digital even internally.  I assume of course
> > that his HDMI TV *is* a DFP.
> 
> But at some point the 1s and 0s must be converted to some sort of an
> analog signal if only right behind the diode.  A diode must be
> presented with a signal in some sort of analog form in order to
> illuminate, right?

no.

If your tv is a standard flat panel, the sub pixels only go from on to off and 
back. Nothing else. There is no analog signal, no transformation nothing. And 
off means 'let light through' and on 'black'

If you have an led display it is pretty much the same. All the levels you see 
are achieved with fast switching. There are no analog levels.

Stroller is probably correct with overscan/underscan.

But that has nothing to do with digital/analog conversion.


> Digital is just a figment of our imagination after
> all.

emm, no, seriously not.

-- 
#163933

Re: Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Daniel Frey]

On 01/-10/37 11:59, Grant wrote:
--snip--
>> The TV is an LG 47LH90 and and it is said to do 1080p.  I looked for
>> ghosting in 16:9 mode instead of Just Scan mode and strangely the
>> shadows are there, but they're oriented top and bottom instead of left
>> and right.  I can take another photo if anyone would like to see.
>>
>> Why do I need to select Just Scan in order to prevent all 4 edges of
>> the screen from being cut off?
>>
>> - Grant
> 
> BTW I think you're on to something Stroller because the overall
> picture is definitely improved in 16:9 mode compared to Just Scan
> mode.  I just need to figure out how to prevent the edges of the
> screen from being cut off.
> 
> - Grant

Grant,

By default most TVs overscan inputs due to broadcast signals at the
edges as the picture there is not well defined and can have white
overscan lines and such. The TV compensates by overscanning which
basically zooms in on the picture making (on my 46" Samsung TV) the
outer 1-1.5" of the picture disappear.

On my TV it was fairly simple to turn this off, I just had to label the
HDMI input as "DVI PC" and it automatically turned off any picture
processing/overscanning. Yours may be similar.

Sorry if there's typos, I have a bandaged finger and it's a PITA to type
with. I think I fixed all of them.

Dan

Re: Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

> --snip--
>>> The TV is an LG 47LH90 and and it is said to do 1080p.  I looked for
>>> ghosting in 16:9 mode instead of Just Scan mode and strangely the
>>> shadows are there, but they're oriented top and bottom instead of left
>>> and right.  I can take another photo if anyone would like to see.
>>>
>>> Why do I need to select Just Scan in order to prevent all 4 edges of
>>> the screen from being cut off?
>>>
>>> - Grant
>>
>> BTW I think you're on to something Stroller because the overall
>> picture is definitely improved in 16:9 mode compared to Just Scan
>> mode.  I just need to figure out how to prevent the edges of the
>> screen from being cut off.
>>
>> - Grant
>
> Grant,
>
> By default most TVs overscan inputs due to broadcast signals at the
> edges as the picture there is not well defined and can have white
> overscan lines and such. The TV compensates by overscanning which
> basically zooms in on the picture making (on my 46" Samsung TV) the
> outer 1-1.5" of the picture disappear.
>
> On my TV it was fairly simple to turn this off, I just had to label the
> HDMI input as "DVI PC" and it automatically turned off any picture
> processing/overscanning. Yours may be similar.
>
> Sorry if there's typos, I have a bandaged finger and it's a PITA to type
> with. I think I fixed all of them.
>
> Dan

I found this:

"We recommend using the Just Scan mode with 1080i and 1080p material,
which assures zero overscan and proper 1:1 pixel matching for this
1080p display."

http://reviews.cnet.com/flat-panel-tvs/lg-47lh90/4505-6482_7-33485570.html#reviewPage1

Just Scan is what I've always used which has the ghosting problem.  I
think I'm back to square one.

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

...
>> >>> I still think it's a driver problem.  Again: it's *physically*
>> >>> impossible to
>> >>> have these problems with the HDMI signal.  At most you get "digital
>> >>> noise",
>> >>> which means some pixels get stuck or are missing.  But not what you
>> >>> get; that's just something that can't be explained.
>> >>
>> >> I was thinking about this.  The digital HDMI signal must be converted
>> >> into an analog signal at some point if it's being represented as light
>> >> on a TV screen.  Electrical interference generated by the computer and
>> >> traveling up the HDMI wire should have its chance to affect things
>> >> (i.e. create weird shadows) at that point, right?
>> >
>> > Not with DFPs.  Those work digital even internally.  I assume of course
>> > that his HDMI TV *is* a DFP.
>>
>> But at some point the 1s and 0s must be converted to some sort of an
>> analog signal if only right behind the diode.  A diode must be
>> presented with a signal in some sort of analog form in order to
>> illuminate, right?
>
> no.
>
> If your tv is a standard flat panel, the sub pixels only go from on to off and
> back. Nothing else. There is no analog signal, no transformation nothing. And
> off means 'let light through' and on 'black'

Every digital signal is encoded into an analog signal.  I think it
would take some serious EMI to sufficiently change the characteristics
of an analog signal so as to create an error in the overlying digital
signal if that signal is traveling along a wire.  I can imagine it
happens but I would think it's rare.  Even if that signal were
altered, I would think it just about impossible that anything but an
error could be produced.

Whether an LED is on or off is determined by whether or not it is
forward biased.  Biasing is established by analog voltages and/or
currents, and those can be altered by EMI.  Again, I would think it's
very rare that EMI could affect an LED's forward biasing and change
its state from on to off or off to on.

However, what color an LED emits is determined by the energy gap of
the semiconductor which is very much an analog process.  How could it
be anything else?  How do you tell a photon to emit a certain color by
feeding it 1's and 0's?  There has to be at least one D/A conversion
somewhere between the digital signal and the emittance of the LED, and
that is the most likely point for EMI to affect the final output.

> If you have an led display it is pretty much the same. All the levels you see
> are achieved with fast switching. There are no analog levels.
>
> Stroller is probably correct with overscan/underscan.
>
> But that has nothing to do with digital/analog conversion.
>
>
>> Digital is just a figment of our imagination after
>> all.
>
> emm, no, seriously not.

It is though.  It only exists in the conceptual world, not the
physical world.  If you want to do anything with your digital signal
besides change it, store it, or transfer it, there must be a D/A
conversion.

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Michael Mol]

On Tue, Jul 19, 2011 at 4:35 PM, Grant <emailgrant@gmail.com> wrote:
> ...
>>> >>> I still think it's a driver problem.  Again: it's *physically*
>>> >>> impossible to
>>> >>> have these problems with the HDMI signal.  At most you get "digital
>>> >>> noise",
>>> >>> which means some pixels get stuck or are missing.  But not what you
>>> >>> get; that's just something that can't be explained.
>>> >>
>>> >> I was thinking about this.  The digital HDMI signal must be converted
>>> >> into an analog signal at some point if it's being represented as light
>>> >> on a TV screen.  Electrical interference generated by the computer and
>>> >> traveling up the HDMI wire should have its chance to affect things
>>> >> (i.e. create weird shadows) at that point, right?
>>> >
>>> > Not with DFPs.  Those work digital even internally.  I assume of course
>>> > that his HDMI TV *is* a DFP.
>>>
>>> But at some point the 1s and 0s must be converted to some sort of an
>>> analog signal if only right behind the diode.  A diode must be
>>> presented with a signal in some sort of analog form in order to
>>> illuminate, right?
>>
>> no.
>>
>> If your tv is a standard flat panel, the sub pixels only go from on to off and
>> back. Nothing else. There is no analog signal, no transformation nothing. And
>> off means 'let light through' and on 'black'
>
> Every digital signal is encoded into an analog signal.  I think it
> would take some serious EMI to sufficiently change the characteristics
> of an analog signal so as to create an error in the overlying digital
> signal if that signal is traveling along a wire.  I can imagine it
> happens but I would think it's rare.  Even if that signal were
> altered, I would think it just about impossible that anything but an
> error could be produced.
>
> Whether an LED is on or off is determined by whether or not it is
> forward biased.  Biasing is established by analog voltages and/or
> currents, and those can be altered by EMI.  Again, I would think it's
> very rare that EMI could affect an LED's forward biasing and change
> its state from on to off or off to on.
>
> However, what color an LED emits is determined by the energy gap of
> the semiconductor which is very much an analog process.  How could it
> be anything else?  How do you tell a photon to emit a certain color by
> feeding it 1's and 0's?  There has to be at least one D/A conversion
> somewhere between the digital signal and the emittance of the LED, and
> that is the most likely point for EMI to affect the final output.
>
>> If you have an led display it is pretty much the same. All the levels you see
>> are achieved with fast switching. There are no analog levels.
>>
>> Stroller is probably correct with overscan/underscan.
>>
>> But that has nothing to do with digital/analog conversion.
>>
>>
>>> Digital is just a figment of our imagination after
>>> all.
>>
>> emm, no, seriously not.
>
> It is though.  It only exists in the conceptual world, not the
> physical world.  If you want to do anything with your digital signal
> besides change it, store it, or transfer it, there must be a D/A
> conversion.

You're thinking of PCM. (And that's what I was thinking of, earlier,
too). I assume Stroller and Volker are talking about PWM, where a
perceived analog value is achieved by rapidly turning a signal from
full-on to full-off.

(Yes, there's no such thing as pure-digital in the physical world. The
confusion here appears to be in PWM vs PCM.)
-- 
:wq

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 2084 bytes --]

On Tuesday 19 Jul 2011 20:41:08 Grant wrote:
> > --snip--
> > 
> >>> The TV is an LG 47LH90 and and it is said to do 1080p.  I looked for
> >>> ghosting in 16:9 mode instead of Just Scan mode and strangely the
> >>> shadows are there, but they're oriented top and bottom instead of left
> >>> and right.  I can take another photo if anyone would like to see.
> >>> 
> >>> Why do I need to select Just Scan in order to prevent all 4 edges of
> >>> the screen from being cut off?
> >>> 
> >>> - Grant
> >> 
> >> BTW I think you're on to something Stroller because the overall
> >> picture is definitely improved in 16:9 mode compared to Just Scan
> >> mode.  I just need to figure out how to prevent the edges of the
> >> screen from being cut off.
> >> 
> >> - Grant
> > 
> > Grant,
> > 
> > By default most TVs overscan inputs due to broadcast signals at the
> > edges as the picture there is not well defined and can have white
> > overscan lines and such. The TV compensates by overscanning which
> > basically zooms in on the picture making (on my 46" Samsung TV) the
> > outer 1-1.5" of the picture disappear.
> > 
> > On my TV it was fairly simple to turn this off, I just had to label the
> > HDMI input as "DVI PC" and it automatically turned off any picture
> > processing/overscanning. Yours may be similar.
> > 
> > Sorry if there's typos, I have a bandaged finger and it's a PITA to type
> > with. I think I fixed all of them.
> > 
> > Dan
> 
> I found this:
> 
> "We recommend using the Just Scan mode with 1080i and 1080p material,
> which assures zero overscan and proper 1:1 pixel matching for this
> 1080p display."
> 
> http://reviews.cnet.com/flat-panel-tvs/lg-47lh90/4505-6482_7-33485570.html#
> reviewPage1
> 
> Just Scan is what I've always used which has the ghosting problem.  I
> think I'm back to square one.

Just a thought:  have you approached the OEM for the TV?  If you could get to 
some technical department they would hopefully advise if this is a setting or 
hardware issue.

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Stroller]

On 19 July 2011, at 20:41, Grant wrote:
> ...
> I found this:
> 
> "We recommend using the Just Scan mode with 1080i and 1080p material,
> which assures zero overscan and proper 1:1 pixel matching for this
> 1080p display."
> 
> http://reviews.cnet.com/flat-panel-tvs/lg-47lh90/4505-6482_7-33485570.html#reviewPage1
> 
> Just Scan is what I've always used which has the ghosting problem.  I
> think I'm back to square one.

I think the Windows versions of the nVidia drivers have options to over- or under-scan.

This compensates for (older?) TVs which have no way to switch to a "just scan" mode. So the graphics card will, I think, output a slightly over-sized picture, then the telly will scale it down a bit back to normal size. This will not produce a perfect picture, but if overscan on the TV cannot be disabled, then there is no better choice.

Is it possible they have recently added this feature to the Linux nVidia driver?

Stroller.

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Michael Mol]

On Wed, Jul 20, 2011 at 10:29 AM, Stroller
<stroller@stellar.eclipse.co.uk> wrote:
>
> On 19 July 2011, at 20:41, Grant wrote:
>> ...
>> I found this:
>>
>> "We recommend using the Just Scan mode with 1080i and 1080p material,
>> which assures zero overscan and proper 1:1 pixel matching for this
>> 1080p display."
>>
>> http://reviews.cnet.com/flat-panel-tvs/lg-47lh90/4505-6482_7-33485570.html#reviewPage1
>>
>> Just Scan is what I've always used which has the ghosting problem.  I
>> think I'm back to square one.
>
> I think the Windows versions of the nVidia drivers have options to over- or under-scan.
>
> This compensates for (older?) TVs which have no way to switch to a "just scan" mode. So the graphics card will, I think, output a slightly over-sized picture, then the telly will scale it down a bit back to normal size. This will not produce a perfect picture, but if overscan on the TV cannot be disabled, then there is no better choice.
>
> Is it possible they have recently added this feature to the Linux nVidia driver?

Possibly related observation: On my 720p TV, if I output (via HDMI)
720p to it, I lose the outer ten or so pixels off of each side of the
screen. NVidia video card configuration tool indicated a higher
resolution was available, 13??x???, which resulted in a fine picture
with no missing pixels, once I switched to it. This was about a year
ago. (Can't easily test, now, because I no longer have a PC hooked up
to that TV)

-- 
:wq

Re: [gentoo-user] Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> > --snip--
>> >
>> >>> The TV is an LG 47LH90 and and it is said to do 1080p.  I looked for
>> >>> ghosting in 16:9 mode instead of Just Scan mode and strangely the
>> >>> shadows are there, but they're oriented top and bottom instead of left
>> >>> and right.  I can take another photo if anyone would like to see.
>> >>>
>> >>> Why do I need to select Just Scan in order to prevent all 4 edges of
>> >>> the screen from being cut off?
>> >>>
>> >>> - Grant
>> >>
>> >> BTW I think you're on to something Stroller because the overall
>> >> picture is definitely improved in 16:9 mode compared to Just Scan
>> >> mode.  I just need to figure out how to prevent the edges of the
>> >> screen from being cut off.
>> >>
>> >> - Grant
>> >
>> > Grant,
>> >
>> > By default most TVs overscan inputs due to broadcast signals at the
>> > edges as the picture there is not well defined and can have white
>> > overscan lines and such. The TV compensates by overscanning which
>> > basically zooms in on the picture making (on my 46" Samsung TV) the
>> > outer 1-1.5" of the picture disappear.
>> >
>> > On my TV it was fairly simple to turn this off, I just had to label the
>> > HDMI input as "DVI PC" and it automatically turned off any picture
>> > processing/overscanning. Yours may be similar.
>> >
>> > Sorry if there's typos, I have a bandaged finger and it's a PITA to type
>> > with. I think I fixed all of them.
>> >
>> > Dan
>>
>> I found this:
>>
>> "We recommend using the Just Scan mode with 1080i and 1080p material,
>> which assures zero overscan and proper 1:1 pixel matching for this
>> 1080p display."
>>
>> http://reviews.cnet.com/flat-panel-tvs/lg-47lh90/4505-6482_7-33485570.html#
>> reviewPage1
>>
>> Just Scan is what I've always used which has the ghosting problem.  I
>> think I'm back to square one.
>
> Just a thought:  have you approached the OEM for the TV?  If you could get to
> some technical department they would hopefully advise if this is a setting or
> hardware issue.

That may be.  I'll try that.  Please let me know if you think this may
be a software issue of some sort.

- Grant

Re: [gentoo-user] Re: Problem with xf86-video-ati & nvidia-drivers

[Grant]

>> ...
>>>> >> I was thinking about this.  The digital HDMI signal must be converted
>>>> >> into an analog signal at some point if it's being represented as light
>>>> >> on a TV screen.  Electrical interference generated by the computer and
>>>> >> traveling up the HDMI wire should have its chance to affect things
>>>> >> (i.e. create weird shadows) at that point, right?
>>>> >
>>>> > Not with DFPs.  Those work digital even internally.  I assume of course
>>>> > that his HDMI TV *is* a DFP.
>>>>
>>>> But at some point the 1s and 0s must be converted to some sort of an
>>>> analog signal if only right behind the diode.  A diode must be
>>>> presented with a signal in some sort of analog form in order to
>>>> illuminate, right?
>>>
>>> no.
>>>
>>> If your tv is a standard flat panel, the sub pixels only go from on to off and
>>> back. Nothing else. There is no analog signal, no transformation nothing. And
>>> off means 'let light through' and on 'black'
>>
>> Every digital signal is encoded into an analog signal.  I think it
>> would take some serious EMI to sufficiently change the characteristics
>> of an analog signal so as to create an error in the overlying digital
>> signal if that signal is traveling along a wire.  I can imagine it
>> happens but I would think it's rare.  Even if that signal were
>> altered, I would think it just about impossible that anything but an
>> error could be produced.
>>
>> Whether an LED is on or off is determined by whether or not it is
>> forward biased.  Biasing is established by analog voltages and/or
>> currents, and those can be altered by EMI.  Again, I would think it's
>> very rare that EMI could affect an LED's forward biasing and change
>> its state from on to off or off to on.
>>
>> However, what color an LED emits is determined by the energy gap of
>> the semiconductor which is very much an analog process.  How could it
>> be anything else?  How do you tell a photon to emit a certain color by
>> feeding it 1's and 0's?  There has to be at least one D/A conversion
>> somewhere between the digital signal and the emittance of the LED, and
>> that is the most likely point for EMI to affect the final output.
>>
>>> If you have an led display it is pretty much the same. All the levels you see
>>> are achieved with fast switching. There are no analog levels.
>>>
>>> Stroller is probably correct with overscan/underscan.
>>>
>>> But that has nothing to do with digital/analog conversion.
>>>
>>>
>>>> Digital is just a figment of our imagination after
>>>> all.
>>>
>>> emm, no, seriously not.
>>
>> It is though.  It only exists in the conceptual world, not the
>> physical world.  If you want to do anything with your digital signal
>> besides change it, store it, or transfer it, there must be a D/A
>> conversion.
>
> You're thinking of PCM. (And that's what I was thinking of, earlier,
> too). I assume Stroller and Volker are talking about PWM, where a
> perceived analog value is achieved by rapidly turning a signal from
> full-on to full-off.
>
> (Yes, there's no such thing as pure-digital in the physical world. The
> confusion here appears to be in PWM vs PCM.)
> --
> :wq

Everything I said above applies to both PCM and PWM.  They are only
conceptual layers built on top of a physical/analog base.  PWM
switching from full-on to full-off and back is an analog process
representing digital data in order to represent an analog signal.

- Grant