Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #13460 > unrolled thread

Re: Hk Cqvst wrote: nVidia + gamma !FIXED!

Back to article view | Back to comp.os.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Hk Cqvst wrote: nVidia + gamma !FIXED! not.socialnetwork@gmail.com - 2015-01-19 13:43 +0000
    Re: Hk Cqvst wrote: nVidia + gamma !FIXED! Rich <rich@example.invalid> - 2015-01-19 17:32 +0000
      Re: Hk Cqvst wrote: nVidia + gamma !FIXED! Avoid9Pdf@gmail.com - 2015-01-20 18:47 +0000
        Re: Hk Cqvst wrote: nVidia + gamma !FIXED! Jerry Peters <jerry@example.invalid> - 2015-01-20 21:16 +0000
          Re: Hk Cqvst wrote: nVidia + gamma !FIXED! Unknown <dog@gmail.com> - 2015-01-21 11:59 +0000
            Re: Hk Cqvst wrote: nVidia + gamma !FIXED! Rich <rich@example.invalid> - 2015-01-21 12:17 +0000
              Re: Hk Cqvst wrote: nVidia + gamma !FIXED! no.top.post@gmail.com - 2015-01-27 19:25 +0000
            Re: Hk Cqvst wrote: nVidia + gamma !FIXED! Jerry Peters <jerry@example.invalid> - 2015-01-21 21:18 +0000
        Re: Hk Cqvst wrote: nVidia + gamma !FIXED! "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2015-01-20 16:50 -0500

#13460 — Re: Hk Cqvst wrote: nVidia + gamma !FIXED!

In article <m9b56p$nhh$1@dont-email.me>, Rich <rich@example.invalid> wrote: 

> Unknown <dog@gmail.com> wrote:
> > How could I disable/prevent the sleep-mode.
> 
> With the "xset" utility.
> 
>   xset s off
> 
> turns off the screen saver, and
> 
>   xset -dpms off 
> 
> turns off the power saving shutdown features
> 
> Or, at least those two are supposed to do so.  Buggy drivers might
> ignore such requests due to the bugs.
> ============
xset s off
xset -dpms
     'fixed it' but before I die I want to KNOW why/what.
     
Why should the <video driver> go from good after boot, to bad after 
the system is left unattended?  And that <disable/prevent the 
sleep-mode> avoids the problem?

It's been running for 3 days beeootifully.

Is the video-driver inside the 
 4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
or in the case of the few-months OLDER version which does NOT have the
problem, inside the <initrd.gz>

== Thanks.

[toc] | [next] | [standalone]

#13461

In comp.os.linux.misc not.socialnetwork@gmail.com wrote:
> In article <m9b56p$nhh$1@dont-email.me>, Rich <rich@example.invalid> wrote: 

> > Unknown <dog@gmail.com> wrote:
> > > How could I disable/prevent the sleep-mode.
> > 
> > With the "xset" utility.
> > 
> >   xset s off
> > 
> > turns off the screen saver, and
> > 
> >   xset -dpms off 
> > 
> > turns off the power saving shutdown features
> > 
> > Or, at least those two are supposed to do so.  Buggy drivers might
> > ignore such requests due to the bugs.
> > ============
> xset s off
> xset -dpms
>      'fixed it' but before I die I want to KNOW why/what.
>      
> Why should the <video driver> go from good after boot, to bad after 
> the system is left unattended?  And that <disable/prevent the 
> sleep-mode> avoids the problem?

A bug in the video driver code, related to how the driver enables
dpms[1] turn off/turn on, for your specific revision of the video chip. 
There is likely some register value that your chip revision needs set a
certian way, and the driver simply is not setting it the right way.

Determining any more of a "why" than the above will require you to:

  1) start digging into the C code for the video driver for your chip;
  2) have available to detailed programming specs. from the
     manufacturer for your specific model/revision, including all
     erratta.
  3) hope that the documentation is complete and accurate

> It's been running for 3 days beeootifully.

> Is the video-driver inside the 
>  4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
> or in the case of the few-months OLDER version which does NOT have the
> problem, inside the <initrd.gz>

Part of the compiled binary of the driver is in one or the other.  the
remainder is within the X server driver.  The compiled binaries will do
you no good if you truly want to know "why".  You'll have to dig into
the C code for the answer to that question.


[1] I point at dpms here because dpms is the mode that requires
programming the chipset to do something special.  There's a bug there
somewhere from the sounds of things.

[toc] | [prev] | [next] | [standalone]

#13466

In article <m9jf2n$pq3$2@dont-email.me>, Rich <rich@example.invalid> wrote: 

> > xset s off
> > xset -dpms
> >      'fixed it' but before I die I want to KNOW why/what.
> >      
> > Why should the <video driver> go from good after boot, to bad after 
> > the system is left unattended?  And that <disable/prevent the 
> > sleep-mode> avoids the problem?
> 
> A bug in the video driver code, related to how the driver enables
> dpms[1] turn off/turn on, for your specific revision of the video chip. 
> There is likely some register value that your chip revision needs set a
> certian way, and the driver simply is not setting it the right way.
> 
> Determining any more of a "why" than the above will require you to:
> 
>   1) start digging into the C code for the video driver for your chip;
>   2) have available to detailed programming specs. from the
>      manufacturer for your specific model/revision, including all
>      erratta.
>   3) hope that the documentation is complete and accurate
> 
> > It's been running for 3 days beeootifully.
> 
> > Is the video-driver inside the 
> >  4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
> > or in the case of the few-months OLDER version which does NOT have the
> > problem, inside the <initrd.gz>
> 
> Part of the compiled binary of the driver is in one or the other.  the
> remainder is within the X server driver.  The compiled binaries will do
> you no good if you truly want to know "why".  You'll have to dig into
> the C code for the answer to that question.
> 
> 
> [1] I point at dpms here because dpms is the mode that requires
> programming the chipset to do something special.  There's a bug there
> somewhere from the sounds of things.

Remember the other quirk: that their's no problem, when a CRT is plugged
instead of the new LED:1920x1080. 
--
My Windows-using mate insists that the vga is bidirectional; ie. that the
display informs the PC <what settings it needs>.
Since the modern LED:1920x1080 is forced to comply with the OLD vga
spec. [and pin-out}, I don't believe him.

[toc] | [prev] | [next] | [standalone]

#13469

In alt.os.linux.slackware Avoid9Pdf@gmail.com wrote:
> In article <m9jf2n$pq3$2@dont-email.me>, Rich <rich@example.invalid> wrote: 
> 
>> > xset s off
>> > xset -dpms
>> >      'fixed it' but before I die I want to KNOW why/what.
>> >      
>> > Why should the <video driver> go from good after boot, to bad after 
>> > the system is left unattended?  And that <disable/prevent the 
>> > sleep-mode> avoids the problem?
>> 
>> A bug in the video driver code, related to how the driver enables
>> dpms[1] turn off/turn on, for your specific revision of the video chip. 
>> There is likely some register value that your chip revision needs set a
>> certian way, and the driver simply is not setting it the right way.
>> 
>> Determining any more of a "why" than the above will require you to:
>> 
>>   1) start digging into the C code for the video driver for your chip;
>>   2) have available to detailed programming specs. from the
>>      manufacturer for your specific model/revision, including all
>>      erratta.
>>   3) hope that the documentation is complete and accurate
>> 
>> > It's been running for 3 days beeootifully.
>> 
>> > Is the video-driver inside the 
>> >  4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
>> > or in the case of the few-months OLDER version which does NOT have the
>> > problem, inside the <initrd.gz>
>> 
>> Part of the compiled binary of the driver is in one or the other.  the
>> remainder is within the X server driver.  The compiled binaries will do
>> you no good if you truly want to know "why".  You'll have to dig into
>> the C code for the answer to that question.
>> 
>> 
>> [1] I point at dpms here because dpms is the mode that requires
>> programming the chipset to do something special.  There's a bug there
>> somewhere from the sounds of things.
> 
> Remember the other quirk: that their's no problem, when a CRT is plugged
> instead of the new LED:1920x1080. 
> --
> My Windows-using mate insists that the vga is bidirectional; ie. that the
> display informs the PC <what settings it needs>.
> Since the modern LED:1920x1080 is forced to comply with the OLD vga
> spec. [and pin-out}, I don't believe him.
> 
Try looking up EDID. From wikipedia:
The EDID includes manufacturer name and serial number, product type,
phosphor or filter type, timings supported by the display, display
size, luminance data and (for digital displays only) pixel mapping
data.

Note the luminance data. It could poossibly be your display
mis-informing the video card or its driver about its requirements.

You assume that the video card and driver behave exactly the same with
the CRT and the LCD displays.

[toc] | [prev] | [next] | [standalone]

#13473

On Tue, 20 Jan 2015 21:16:18 +0000, Jerry Peters wrote:

> In alt.os.linux.slackware Avoid9Pdf@gmail.com wrote:
>> In article <m9jf2n$pq3$2@dont-email.me>, Rich <rich@example.invalid>
>> wrote:
>> 
>>> > xset s off
>>> > xset -dpms
>>> >      'fixed it' but before I die I want to KNOW why/what.
>>> >      
>>> > Why should the <video driver> go from good after boot, to bad after
>>> > the system is left unattended?  And that <disable/prevent the
>>> > sleep-mode> avoids the problem?
>>> 
>>> A bug in the video driver code, related to how the driver enables
>>> dpms[1] turn off/turn on, for your specific revision of the video
>>> chip. There is likely some register value that your chip revision
>>> needs set a certian way, and the driver simply is not setting it the
>>> right way.
>>> 
>>> Determining any more of a "why" than the above will require you to:
>>> 
>>>   1) start digging into the C code for the video driver for your chip;
>>>   2) have available to detailed programming specs. from the
>>>      manufacturer for your specific model/revision, including all
>>>      erratta.
>>>   3) hope that the documentation is complete and accurate
>>> 
>>> > It's been running for 3 days beeootifully.
>>> 
>>> > Is the video-driver inside the
>>> >  4940304 2009-08-17 07:53 vmlinuz-huge-smp-2.6.29.6-smp
>>> > or in the case of the few-months OLDER version which does NOT have
>>> > the problem, inside the <initrd.gz>
>>> 
>>> Part of the compiled binary of the driver is in one or the other.  the
>>> remainder is within the X server driver.  The compiled binaries will
>>> do you no good if you truly want to know "why".  You'll have to dig
>>> into the C code for the answer to that question.
>>> 
>>> 
>>> [1] I point at dpms here because dpms is the mode that requires
>>> programming the chipset to do something special.  There's a bug there
>>> somewhere from the sounds of things.
>> 
>> Remember the other quirk: that their's no problem, when a CRT is
>> plugged instead of the new LED:1920x1080.
>> --
>> My Windows-using mate insists that the vga is bidirectional; ie. that
>> the display informs the PC <what settings it needs>. Since the modern
>> LED:1920x1080 is forced to comply with the OLD vga spec. [and pin-out},
>> I don't believe him.
>> 
> Try looking up EDID. From wikipedia:
> The EDID includes manufacturer name and serial number, product type,
> phosphor or filter type, timings supported by the display, display size,
> luminance data and (for digital displays only) pixel mapping data.
> 
> Note the luminance data. It could poossibly be your display
> mis-informing the video card or its driver about its requirements.
> 
> You assume that the video card and driver behave exactly the same with
> the CRT and the LCD displays.
---
Yes, I don't believe that any signal goes from the display to the PC's
vga connector. Ie. it's NOT bidirectional.
Why else would the human need to tell the system about the displays 
parameters?

I looked at the EDID wiki, and don't like it;
although I can read/write schematic diagrams and design hardware.
The explanations [wiki] must be structured: like top-down-software.

[toc] | [prev] | [next] | [standalone]

#13474

In comp.os.linux.misc Unknown <dog@gmail.com> wrote:
> On Tue, 20 Jan 2015 21:16:18 +0000, Jerry Peters wrote:
> > In alt.os.linux.slackware Avoid9Pdf@gmail.com wrote:
> >> My Windows-using mate insists that the vga is bidirectional; ie. that
> >> the display informs the PC <what settings it needs>. Since the modern
> >> LED:1920x1080 is forced to comply with the OLD vga spec. [and pin-out},
> >> I don't believe him.
> >> 
> > Try looking up EDID. From wikipedia:
> > The EDID includes manufacturer name and serial number, product type,
> > phosphor or filter type, timings supported by the display, display size,
> > luminance data and (for digital displays only) pixel mapping data.
> > 
> > Note the luminance data. It could poossibly be your display
> > mis-informing the video card or its driver about its requirements.
> > 
> > You assume that the video card and driver behave exactly the same with
> > the CRT and the LCD displays.
> ---
> Yes, I don't believe that any signal goes from the display to the PC's
> vga connector. Ie. it's NOT bidirectional.
> Why else would the human need to tell the system about the displays 
> parameters?

> I looked at the EDID wiki, and don't like it;
> although I can read/write schematic diagrams and design hardware.
> The explanations [wiki] must be structured: like top-down-software.

While you are certianly free to "believe" whatever you want, in this
case your beief would be wrong.  The EDID signal most definetly goes
_from_ the display _to_ the video card.  It is used so that the display
can tell the computer what resolutions the display supports, to allow
the computer to auto-configure a compatible resolution (presuming one
has "auto-configure" turned on in one's OS).

Now, while the EDID signal technically makes the cable bi-directional,
99.99999% of the information transfer is uni-directional because the
EDID signal is typically only transmitted from the display to the
computer once, at initialization (or at display plug-in) time.

If you dislike the EDID web page (and you are also free to dislike that
page, but your dislike does not change the accuracy of the information
provided thereupon), try looking up EDID on Wikipedia instead, where
the EDID page
(http://en.wikipedia.org/wiki/Extended_display_identification_data)
says this as its first sentence:

    Extended display identification data (EDID) is a data structure
    provided by a digital display to describe its capabilities to a
    video source (e.g. graphics card or set-top box).

The only way that this "structure" can be "provided by ... a ...
display" ... "to a video source" is with a return data channel in the
video cable running _from_ the display _to_ the video source.

[toc] | [prev] | [next] | [standalone]

#13499

In article <m9o5d2$2k0$1@dont-email.me>, nobody wrote: 

> In comp.os.linux.misc Unknown <dog@gmail.com> wrote:
> > On Tue, 20 Jan 2015 21:16:18 +0000, Jerry Peters wrote:
> > > In alt.os.linux.slackware Avoid9Pdf@gmail.com wrote:
> > >> My Windows-using mate insists that the vga is bidirectional; ie. that
> > >> the display informs the PC <what settings it needs>. Since the modern
> > >> LED:1920x1080 is forced to comply with the OLD vga spec. [and pin-out},
> > >> I don't believe him.
> > >> 
> > > Try looking up EDID. From wikipedia:
> > > The EDID includes manufacturer name and serial number, product type,
> > > phosphor or filter type, timings supported by the display, display size,
> > > luminance data and (for digital displays only) pixel mapping data.
> > > 
> > > Note the luminance data. It could poossibly be your display
> > > mis-informing the video card or its driver about its requirements.
> > > 
> > > You assume that the video card and driver behave exactly the same with
> > > the CRT and the LCD displays.
> > ---
> > Yes, I don't believe that any signal goes from the display to the PC's
> > vga connector. Ie. it's NOT bidirectional.
> > Why else would the human need to tell the system about the displays 
> > parameters?
> 
> > I looked at the EDID wiki, and don't like it;
> > although I can read/write schematic diagrams and design hardware.
> > The explanations [wiki] must be structured: like top-down-software.
> 
> While you are certianly free to "believe" whatever you want, in this
> case your beief would be wrong.  The EDID signal most definetly goes
> _from_ the display _to_ the video card.  It is used so that the display
> can tell the computer what resolutions the display supports, to allow
> the computer to auto-configure a compatible resolution (presuming one
> has "auto-configure" turned on in one's OS).
> 
> Now, while the EDID signal technically makes the cable bi-directional,
> 99.99999% of the information transfer is uni-directional because the
> EDID signal is typically only transmitted from the display to the
> computer once, at initialization (or at display plug-in) time.
> 
> If you dislike the EDID web page (and you are also free to dislike that
> page, but your dislike does not change the accuracy of the information
> provided thereupon), try looking up EDID on Wikipedia instead, where
> the EDID page
> (http://en.wikipedia.org/wiki/Extended_display_identification_data)
> says this as its first sentence:
> 
Yes, I was stressed-out by the terrorism of the spook that worked OK,
until I left it unattended.  Later I put the EDID-wiki, that Dave Hodgins
cited,  on TestToSpeech and heard it at my leisure.

>     Extended display identification data (EDID) is a data structure
>     provided by a digital display to describe its capabilities to a
>     video source (e.g. graphics card or set-top box).
> 
> The only way that this "structure" can be "provided by ... a ...
> display" ... "to a video source" is with a return data channel in the
> video cable running _from_ the display _to_ the video source.
> 
Yes, they managed to fit it on the connector pin-out. They
couldn't have anticipated such a need at the time of the original
design.

With the solid-state display PRETENDING to be a CRT, it gets
very complex. The symptom of the gray-signal-range showing
as white seemed like the 'ball hitting multiple RGB parts'.
But as I explained, it's NOT a CRT with a free-flying beam.
It's digital/discrete.

OTOH, if the timing is marginal, some red-balls may go in the 
adjacent 'G/B-holes', effectively 'leaking the paint' to give white.

So I'd still like to know how fiddling the gamma
correction improved it somewhat.

== Thanks.

[toc] | [prev] | [next] | [standalone]

#13482

In alt.os.linux.slackware Unknown <dog@gmail.com> wrote:
> On Tue, 20 Jan 2015 21:16:18 +0000, Jerry Peters wrote:
> 
> Yes, I don't believe that any signal goes from the display to the PC's
> vga connector. Ie. it's NOT bidirectional.

Of course it's bidirectional, how else do you think the EDID gets from
the display to the video card and then to the X server, magic?

> Why else would the human need to tell the system about the displays 
> parameters?

But you *don't*. The X server in 14.1 configures the video card &
monitor *all by itself* using the EDID. Only if there's no EDID do you
need to provide modelines.

> 
> I looked at the EDID wiki, and don't like it;
> although I can read/write schematic diagrams and design hardware.
> The explanations [wiki] must be structured: like top-down-software.
> 
> 

[toc] | [prev] | [next] | [standalone]

#13470

On Tue, 20 Jan 2015 13:47:47 -0500, <Avoid9Pdf@gmail.com> wrote:

> My Windows-using mate insists that the vga is bidirectional; ie. that the
> display informs the PC <what settings it needs>.
> Since the modern LED:1920x1080 is forced to comply with the OLD vga
> spec. [and pin-out}, I don't believe him.

See http://en.wikipedia.org/wiki/Extended_display_identification_data

Regards, Dave Hodgins

-- 
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web