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


Groups > comp.os.linux.misc > #13499

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

From no.top.post@gmail.com
Newsgroups comp.os.linux.misc, alt.os.linux.slackware, alt.os.linux.debian
Subject Re: Hk Cqvst wrote: nVidia + gamma !FIXED!
Date 2015-01-27 19:25 +0000
Organization A noiseless patient Spider
Message-ID <ma8on0$pfp$1@dont-email.me> (permalink)
References <m9o5d2$2k0$1@dont-email.me>

Cross-posted to 3 groups.

Show all headers | View raw


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.

Back to comp.os.linux.misc | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web