[RndTbl] recommendations for 4k video card under Linux

Mon Apr 23 11:28:45 CDT 2018

Just a quick follow-up on how things went: really quite smoothly! I 
never had to change any configuration or install any drivers. It 
autodetected the new card with no problems. The logs didn't clearly show 
what was going on behind the scenes, just that it was now using a 
"glamoregl" module and glamor OpenGL accelerated driver that it wasn't 
using before. No feedback on detected chipset or anything of the sort. 
But it worked well. Then I hooked up the new 4k monitor, and initially 
only the top left quarter of the display showed a clear 1080p image of 
the login screen, with noise on the other 3 quarters, but when I logged 
in it displayed a vivid 4k desktop with very tiny fonts. I spent a bit 
of time playing around in the Gnome Tweak Tool and dconf-editor to get 
things showing up to my satisfaction. Looks & works great now! The login 
screen displays properly now too, albeit with small text, but not worth 
fussing with to get that larger.

On 2018-04-09 14:31, Gilles Detillieux wrote:
> Thanks, everyone, for all the advice. It does put my mind at ease that 
> nVidia seems to be a safer bet than I had thought. I think we'll give 
> a GTX 1050 card a try. We'll likely stick to DisplayPort 1.4, which 
> should do 4k without a snag, and avoid the potential headaches of 
> HDMI. Don't need 5k, don't need more than 1 monitor so we won't be 
> messing with passthrough/daisychain, and won't wait for TB3. ;-)
>
> Gilles (unrepentant top-poster)
>
> On 2018-04-07 11:08, Adam Thompson wrote:
>> (Top-posting to save time, sorry)
>>
>> You need HDMI 2.1 for guaranteed 5k support.  IIRC, HDMI 2.0 
>> guaranteed 4k support.
>> When I say "guaranteed", I don't mean "HDMI Assoc. says it'll work", 
>> I mean "yes, it's going to work in the real world".
>>
>> Hanging a non-passthrough DP monitor off of a passthrough-capable 
>> monitor is exactly the use case that feature is designed for.
>>
>> I sincerely hope that TB3 takes over as a video cabling standard and 
>> finally replaces both DP and HDMI, but I don't really think it'll 
>> happen...  in any case a single 40GBps TB3 connection still only 
>> supports 1 x 5k or 2 x 4k displays.
>>
>> -Adam
>>
>>
>> On 2018-04-07 01:19, Trevor Cordes wrote:
>>> On 2018-04-06 Gilles Detillieux wrote:
>>>> Hi. Does anyone on the list have experience and recommendations on
>>>> how to support a 4k monitor under Linux? We want to use a single Dell
>>>
>>> Hi, I mentioned at a MUUG meeting roundtable last year that I had
>>> picked up a "2k" (2560x1440) monitor and card and got it working.  All
>>> my research and picks apply to 4k also, so my results might be 
>>> useful to
>>> you.
>>>
>>> First off, you want DP.  2k is hard with HDMI, and 4k is doubly so.
>>> Many cards (especially cheaper/older ones) may claim to do high rez's
>>> but their HDMI out port won't, as it's not a new enough spec. From
>>> memory, you need something like 1.6 instead of 1.4 or whatever (can 
>>> find
>>> online) but good luck finding out precisely what the HDMI port on your
>>> card actually is from the Taiwan Inc websites.
>>>
>>> Same thing applies to cables, for 4k you'll probably need a newest-gen
>>> cable, and they are equally as hard to deduce precisely what version
>>> they are!  DP doesn't suffer from this problem on either front. If you
>>> get a DP card that says it does 4k, it does 4k, guaranteed, and the
>>> cables are basically all 4k supporting unless you find something really
>>> old.
>>>
>>> I tried about 4 different combos of card and 2k monitor before finally
>>> getting something to work, so I'm pretty sure I've figured out the
>>> cheapest (nvidia) way.  And when things aren't going to work, they just
>>> don't work.  You're just stuck at the lower rez with no option to go
>>> higher and no hint as to why.  I suppose you could probably get things
>>> working at lower clocks using xorg.conf modelines like the bad 'ol
>>> days, but I didn't want to delve there.  When you get the right parts
>>> it all "just works".
>>>
>>> The cheapest card that I could find that would support 4k and DP and
>>> vdpau (important for me) was the GTX 1050.  Any 1050 with DP out should
>>> be A-OK.  I sell them for just over $200, but I'm sure there are deals
>>> elsewhere out there.
>>>
>>> I'm not 100% positive but I think when I first booted up with my
>>> nouveau drivers they didn't work and it fell back to fb or vesa or
>>> something.  That was 1 year ago.  Eventually nouveau will support the
>>> 1050, maybe already does.  The chipset codename according to lspci is
>>> GP107 if that helps.
>>>
>>> No whoop, I switch between nouveau and nvidia binaries frequently when
>>> FLOSS support catches up with the technology.  "Updating kernel ate my
>>> nv binary" hasn't been a concern for me for at least 5 years now.  If
>>> you're using Fedora, just use the rpmfusion nvidia and (a|)kmod-nvidia
>>> rpms and every time you dnf update the kernel the binaries auto-compile
>>> and you have to do zero additional steps when you reboot.  It just
>>> keeps working.  (And it bypasses having to wait for the repo guys to
>>> update the non-akmod rpm version which always takes 1-2 weeks!)
>>>
>>> One caveat: after the dnf update finishes, wait about 2 minutes for the
>>> gcc processes to finish compiling or you'll be foobar until you run
>>> akmod --somethingorrather from a single boot. (Nothing at all indicates
>>> you need to wait after an update before rebooting.)
>>>
>>> I'm probably stuck with binaries for a long time as I really like vdpau
>>> now and I'm pretty sure that won't be in the FLOSS drivers for many
>>> more years, if ever.  The binaries are pretty good.  No stability
>>> issues, though sometimes there's little cosmetic glitch bugs that they
>>> eventually hammer out in updates (I currently have zero of these
>>> occurring).  The only sucky part is if you want to bisect/debug for the
>>> LKML guys (which I seem to do way too often lately) you'll need to
>>> reproduce your bug in non-tainted before posting your results.
>>>
>>> My monitor is also a Dell (2k) and it's great.  Their quality/price
>>> ratio can't be beat on mid/high-end monitors.  I sell quite a few and
>>> can often get amazing prices on Dell LCDs through my suppliers, so if
>>> you're in Wpg give me a shout.
>>>
>>> My next project is to try the DP daisychain feature as I want 2 x 2k
>>> LCD instead of my current 2k + 1600x1200.  And I'm not convinced the
>>> 1050's HDMI will do 2k or 4k so daisychain might be the only option.
>>> (My big q is can a non-daisy LCD daisy off a has-daisy LCD or do both
>>> need to be daisy-capable, i.e. with passthru.)  If a 2nd 2k/4k monitor
>>> is in your future give the daisy port yes/no feature serious
>>> consideration before you buy your first one.  No "affordable" card I
>>> looked at had dual DP out.
>>>
>>> I'll end with a quick note about 2k vs 4k.  I thought long and hard
>>> about which to buy, as the price diff was sub-$200.  I went with 2k as
>>> I do almost zero graphics/images and I realized that for my workload,
>>> normal daily desktop use + 90% cmd line and programming work, 4k would
>>> buy me nothing.  In fact, besides graphics work I can't see any use for
>>> 4k.  My goal is always the most usable real estate, and with 2k on a
>>> 24" I was able to vastly increase my pixel count yet keep all my
>>> working terminal font sizes constant at 9 pixel mono terminal font.
>>>
>>> I guess what I'm saying (and I'm sure you've already thought about it)
>>> is don't just say "ooooh 4k" and get that, think about what you are
>>> really trying to achieve.  The other upshot of picking 2k, besides
>>> price, is that you can go 2 x 2k fairly easily on most cards, but 2 x
>>> 4k might go beyond the $200 cards' max overall screen dimensions.
>>>
>>> Good luck!  And if you ever daisychain, let me know.
>

-- 
Gilles R. Detillieux              E-mail: <grdetil at scrc.umanitoba.ca>
Spinal Cord Research Centre       WWW:    http://www.scrc.umanitoba.ca/
Dept. of Physiology and Pathophysiology, Faculty of Health Sciences,
Univ. of Manitoba  Winnipeg, MB  R3E 0J9  (Canada)