Thread replies: 14
Thread images: 2
Thread images: 2
Why is X such inexcusable shit? It's almost single-handedly the reason for me having Windows installed. You see, I have this CRT monitor I cling to. These days it stays off most of the time, but I have yet to find a better looking screen for movies. By all rights, getting it working should have been trivial. It's old tech, and I have microsecond-accurate timings straight from the manufacturer. In practice, after making a new display mode and setting it, I'm left with a highly distorted picture. This held constant for ATI, AMD and Nvidia cards, and open source and proprietary drivers alike. By fudging a few numbers and inputting an incorrect sync polarity I could get rid of the distortion (while causing a few other minor problems), but why the fuck should I be doing that in the first place? I had thought the Linux graphics stack was a decade behind, but apparently I was too generous seeing as it can't even properly output the signal parameters you give it.
>>
Another idiot too stupid for simple configurations...
>>
>>55820500
>Why is X such inexcusable shit?
https://people.freedesktop.org/~daniels/lca2013-wayland-x11.pdf
>>
File: timings.png (157KB, 1336x1000px) Image search:
[Google]
157KB, 1336x1000px
>>55820578
Feel free to show me where I went wrong. Manufacturer timings and the modeline I gave xrandr both in the image, because fucking spam filter.
>>
http://web.mit.edu/%7Esimsong/www/ugh.pdf
go to chapter 7
>>
>>55821268
Do you know any resources I can use to learn about modelines and what it all means?
>>
>>55821565
https://www.mythtv.org/wiki/Working_with_Modelines
Look at the "Working with Modelines by Hand" section for a concise overview. First value is pixel clock. Second is active horizontal pixels. Third, fourth and fifth come from cumulatively adding the front porch, sync width, and back porch in that order. The next four are a repeat of this process for vertical lines, starting with the active lines and progessively adding on front porch, sync and back porch. Last two parts specify the sync polarity for each of horizontal and vertical. Then again, if I'm getting something wrong, listening to me isn't productive. Tying things back to my specific case just pay attention to the MODE 5 column. Vertical is in lines, which you can use as-is. Horizontal is in microseconds, though, and X needs values in pixels. You can convert between the two using the horizontal scanning frequency.
>>
>>55820663
when does that come out like 2019 lol will it work on vr headsets lol year of the desktop amirite
>>
>>55822948
>works right now
>gnome uses it be default
Nice try faggot.
>>
tfw redhat made you configure x like this in 2004
tfw newfags can't edit x configs
tfw redhat 9 was harder to install than arch
: /
>>
>>55822059
damn i haven't fucked with modelines in over a decade, maybe your monitor has buggy EDID
>>
>>55823175
Definitely not an EDID issue. Already ruled that out by trying the BNC RGBHV input on the monitor instead of VGA. Same deal. The monitor works fine on every version of Windows I've tested, both on it's own and with a manual EDID override to check I got the timings right. For all the things Windows does wrong, I'm not concerned about it doing anything non-standard with its graphics output, so I take that to mean it's not a problem with the monitor or with Windows. Thinking back to it, one of the *BSDs worked properly too, so maybe X is only part of the problem. All I know is that no DE, WM, distro or kernel I tried made any difference. Shit's broken, and fixing it would appear to require a level of fuckery I'm not willing to undergo.
>>
>>55820500
I ONLY use CRTs and it always worked ootb, even with gentoo.
Anyway if your monitor has a special case just backup the config and you'll never have to deal with it again.
>>
i hate how so many people are forcing the separate xorg conf files
i miss the monolithic xorg.conf
Thread posts: 14
Thread images: 2
Thread images: 2