<br><br>On Tuesday, 30 March 2021, o1bigtenor <<a href="mailto:o1bigtenor@gmail.com" target="_blank">o1bigtenor@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Mar 30, 2021 at 9:21 AM Russell Reiter <<a href="mailto:rreiter91@gmail.com" target="_blank">rreiter91@gmail.com</a>> wrote:<br>
><br>
> On Tue, Mar 30, 2021, 9:50 AM o1bigtenor via talk, <<a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a>> wrote:<br>
>><br>
>> On Tue, Mar 30, 2021 at 8:00 AM Russell Reiter via talk <<a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Tue, Mar 30, 2021, 1:33 AM Evan Leibovitch via talk, <<a href="mailto:talk@gtalug.org" target="_blank">talk@gtalug.org</a>> wrote:<br>
>><br>
>> Having spent quite a few hours working on things in this area I have<br>
>> found a few things.<br>
>> ><br>
>> ><br>
>> > IMO I think the issue is actually due the display EDID provided by many monitor / tv manufacturers is lacking in certain format/reporting respects. While linux autodetection generally works well in most use cases, this is the type of problem linux users have historically faced. I think this is probably due, not in any small part, to certain anti competetative practices.<br>
>><br>
>> Linux auto-detection is based on manufacturers adhering to standards.<br>
>><br>
>> EDID has become a joke - - - - the kernel docs talk about this - - -<br>
>> so its not just my opinion.<br>
><br>
><br>
> I wouldnt nesessarily call EDID a joke. I mean what exactly is the alternative. With it you are at least able to parse the binary and output more human understandable xml structure, which you may then use to try and craft a customised solution for yourself.<br>
<br>
Hmm - - - I don't think you're understanding - - - - you are assuming<br>
that the data parsed is relevant and accurate.<br>
When it is not accurate and/or incomplete - - - - what is it?<br>
IMO that's a sick joke.</blockquote><div><br></div><div>What I am assuming is that data is provided and comes from a source. It's not a set of instructions, it is purely information. What makes it relevant is the place it comes from. What makes it accurate or inaccurate is that either the information accurately represents a fact a manufacturer wants to make public or it does not.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
><br>
>> DeviceID should work better but really doesn't have any kind of real<br>
>> linux connection.<br>
>> At least nvidia - - - - well - - - - they're not too worried about<br>
>> adhering to any standard either - - - why should they - - - they KNOW<br>
>> they own the market (at least only some 80+%).<br>
>> My LG 4k monitor is actually made by Goldstar.<br>
>> The extreme level of profits desired in the industry means that cheap<br>
>> manufacture wins.<br>
>> Also means that details that aren't considered crucial - - - -well - -<br>
>> - they're just ignored!<br>
>> ><br>
>> > Take for example the issues with devices using ccd. The lack of linux friendly colour profiles for ccd is one of the largest barriers to linux users in their choices of scanners and cameras etc.<br>
>> ><br>
>> > I think in this case a closer look at the EDID for each monitor, assuming they are not exact duplicates of each other, may provide a workable solution. In fact it may be fixed already in a kernel/firmware upgrade.<br>
>> ><br>
>> > If that is not possible/desirable then xrandr, get-edid and parse-edid will provide a better understanding of the autogeneration of the display modelines used by Xorg or whatever server is used.<br>
>><br>
>> What is so very fascinating is that both get-edid and parse-edid<br>
>> really aren't that useful.<br>
><br>
><br>
> I have found them very useful in the past in conjunction with xrandr but personally havent had to use them for quite a number of years. As others have said Linux just works.<br>
<br>
You bet - - - - it just works until it doesn't work.<br>
What does one do then?<br>
<a href="https://www.kernel.org/doc/html/v5.9/admin-guide/edid.html" target="_blank">https://www.kernel.org/doc/htm<wbr>l/v5.9/admin-guide/edid.html</a><br>
Except I just couldn't find anything besides this " "make" in<br>
tools/edid/ " which didn't do anything here.<br>
You bet I didn't know what I was doing - - - - but I also couldn't<br>
find anyone talking about what to do either!</blockquote><div><br></div><div>Maybe because they already know what to do with information as postulated and assume their readership does as well. It's not all that farfetched to assume that people using linux do read the fine manual.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
>> Its not that the tools don't work but the tools rely on information<br>
>> provided and that information is all too often not correct.<br>
>> Changing the incorrect information - - - - well - - - I couldn't find<br>
>> a way to do that.<br>
><br>
><br>
> In some cases is as easy as calling xrandr to author a modeline with the exact specifications it detects after probing as opposed to relying solely on information provided by the manufacturers who may not be entirely concerned with the fact that some users cant just buy the dashboard app they use in their day to day business.<br>
<br>
Hmm - - - - how does one find a modeline?</blockquote><div><br></div><div>Type xrandr modeline into google and see what pops up.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That oh so wonderful EDID indicated that the monitor was made in 2017 and<br>
the company released the product in 2020. Sorta looks like inaccurate<br>
information<br>
and that wasn't the only thing inaccurate so it was time to find<br>
something else.</blockquote><div><br></div><div>Products are rebranded all the time. It's not really necessary to change every bit of esoterica in informatics.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
><br>
>> Enough of the information sites are themselves outdated (lists 4 and 5<br>
>> years old really aren't helpful when working with product release in<br>
>> the last 18 months).<br>
>> ><br>
>> > In fact several solutions I have read in the past point to the fact that you can counterfit a manufactures EDID to overcome video tearing and flicker on both linux and windows.<br>
>><br>
>> This is possible but to do so means hacking at the kernel level.<br>
><br>
><br>
> Not necessarily, I dont hack kernels, I operate in userland. I've solved issues with these tools for this sort of thing in the past and fully expect to do so in the future.<br>
><br>
Best wishes and the best of luck!<br>
</blockquote>
<br><br>-- <br><div dir="ltr"><div><div dir="ltr"><div>Russell<br></div></div></div></div><br>