Official NVIDIA Driver May Cause Unreadable Fonts: An Easy To Follow Solution

Installing the proprietary NVIDIA driver may provide the best performance available from your GPU, but there are circumstances in which it can cause text in menus, files and most other places to be rendered at a size that’s so small, it’s literally unreadable. A living room PC hooked up to a television is one such circumstance in which fonts may become unreadable, but there are other situations too. The problem is often caused by display devices providing incorrect information to the computer, which is apparently something that many televisions and some monitors do.

It’s probably possible to figure out if installing the NVIDIA driver will cause problems with font sizes before you actually install it, but I would imagine it’d much less of a faff to just do step 1 and see if anything more needs to be done.

Step 1
It doesn’t matter if you install the official, proprietary NVIDIA driver before or after you put a script on your desktop to temporarily restore reasonable font sizes, just so long as you do it before you reboot your computer for the first time after installing the driver. To do this, simply create a new file on your desktop, paste the following into it, and then save it:

xrandr --dpi 96
kquitapp5 plasmashell
kstart5 plasmashell

After saving the file, you should make it executable by right clicking the file, selecting “Properties” from the menu, selecting the “Permissions” tab in the window that appears, and then marking the box labelled “Is executable” and clicking OK. Alternatively, you could just do

chmod 700 file-name-here


Having this file in place will ensure that, if you do find that fonts have become unreadably small after a reboot, you have a ready-made solution to the chicken-and-egg-like problem of needing readable font sizes in order to be able to see what you’re doing, so you can make the font sizes readable. With the file in place, you can just click it to make most text readable again while you allpy the more permanent solution outlined in step 2. If text is all fine and readable after the reboot, however, then you can just delete the temporary font fixing file, and get on with doing something more interesting.

Step 2
If you did needed to click the file to make text readable again, then you will probably want to make some minor edits to a couple of files in /etc/X11/xorg.conf.d/ (using the File Manager - Super User Mode. The first file to edit is 50-screen.conf. All that needs to be done, is to uncomment (delete the leading hash symbols from) some lines in the file, and add the line which tells X11 to ignore the EDID data. The EDID data is the information your display device provides to your computer, so that your computer can figure out the proper size at which to draw on-screen elements. Many televisions and some monitors provide incorrect/misleading/useless EDID data so, in these cases, we need to tell the X11 windowing system to disregard the EDID data and use the information we manually provide it. The edited file should look something like the following. Note the uncommented (lines that have had the leading #'s deleted) as well as the line about the EDID.

# Having multiple "Screen" sections is known to be problematic. Make
# sure you don't have in use another one laying around e.g. in another
# xorg.conf.d file or even a generic xorg.conf file. More details can
# be found in
Section "Screen"
  Identifier "Default Screen"
  Option "UseEdidDpi" "FALSE"
  Device "Default Device"

#  ## Doesn't help for radeon/radeonhd drivers; use magic in
#  ## 50-device.conf instead
  Monitor "Default Monitor"


To get an accurate DPI, you would divide a screen’s resolution by its size, but few people actually care about accurate DPI values, and I’m not one of them. So rather than wasting time by trying (and inevitably failing) to accurately measure my screen, I’m going to work in reverse and select a display size calculated by a simple Python script, based on pre-determined DPI values. I’ll give the script the horizontal and vertical resolution of the display, along with maximum and minimum DPI values, and have it produce one DisplaySize command which could be used in 50-monitor.conf, for each combination of width and height where all values turn out to be integers. I chose to use a script to find integer solutions because I didn’t know if if the X Window System needs the screen measurements to be in whole numbers (all the examples I saw used them), and I also thought that using values which produced a DPI value which isn’t an integer, might cause ugly jaggies on fonts, so I just played it safe and knocked together this simple script. Just in case anyone else might find it useful, I’ll post it here. Just like with the other file, just copy/paste the code into a file and make it executable, but call the script from a command line like Konsole instead. Call the script with something like ]code]~/path/to/file-name

 because just clicking on it will not  give you anything you can copy/paste.


Use DPI min/max as a range of sizes you can try out. Try these out these initial values before making them any smaller/larger.

DPIMin = 70
DPIMax = 150

Very important! Don’t forget to make sure these values actually match your display’s resolution.

displayPixelsHorizontal = 1920
displayPixelsVertical = 1080
for tDPI in range(DPIMin, DPIMax + 1):
tWidth = displayPixelsHorizontal * (25 / tDPI)
tHeight = displayPixelsVertical * (25 / tDPI)
if tWidth % 1 == 0 and tHeight % 1 == 0:
print(f’DisplaySize {int(tWidth)} {int(tHeight)}# (In millimeters) makes DPI {tDPI}’)

When you have  a configuration line, just paste it into 50-monitor.conf, then use the cvt tool to have it calculate a Modeline for you which you'll want to paste into the same file.
the cvt tool is used like *]cvt horizontal-pixels vertical-pixels refresh rate*, so in my case it would be

cvt 1920 1080 50code] and produces an output of

# 1920x1080 49.93 Hz (CVT 2.07M9) hsync: 55.62 kHz; pclk: 141.50 MHz
Modeline "1920x1080_50.00"  141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync

Pasting the output from the python script and the cvt tool into 50-monitor.conf should leave you with something along the lines of the following.

# Having multiple "Monitor" sections is known to be problematic. Make
# sure you don't have in use another one laying around e.g. in another
# xorg.conf.d file or even a generic xorg.conf file. More details can
# be found in
Section "Monitor"
  Identifier "Default Monitor"
  DisplaySize 480 270# (In millimeters) makes DPI 100
#  ## If your monitor doesn't support DDC you may override the
#  ## defaults here
#  #HorizSync 28-85
#  #VertRefresh 50-100
#  ## Add your mode lines here, use e.g the cvt tool
  Modeline "1920x1080_50.00"  141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync

After doing this, all of the elements of your User Interface should be clearly visible and useable from the next boot onwards.

Calculating modelines manually with GTF or CVT for use in an Xorg .conf file is an anachronism. X very well knows how to do proper modeline calculations, given the right data, no less well than CVT or GTF. It’s what happens time and time again when EDID is competent. I’ve never yet found a hardware combination that required I put a modeline in a .conf file because X failed to do the calculating correctly using appropriate input data. That data is obtainable via the display’s manual, or various software tools, when EDID isn’t getting it right. In Xorg language, those specs are:

  1. HorizSync
  2. VertRefresh
  3. PreferredMode

#3 often isn’t needed when desiring the display to use its native mode.

So, a 50-monitor.conf file for a typical 1920x1080 TV or PC screen might look like.:

Section "Monitor"
    Identifier "Default Monitor"
	HorizSync	31-70
	VertRefresh	50-77
	Option	"PreferredMode"	"1920x1080"

One no small advantage of letting X to the calculating is you can plug in another display while that config file remains in place and X will not be forcing an inappropriate mode on the different display. Another: fewer opportunities for problematic typos in creating the .conf file.

Thanks for the advice mrmazda. I was hoping for advice and corrections like that so that I could improve the original post by integrating the advice/corrections into it, but I can’t seem to edit the post.

Hey, guys!

This is what I got from the script and CVT use:

alejandro@localhost:~> /home/alejandro/Desktop/DPI_script
DisplaySize 640 360# (In millimeters) makes DPI 75
DisplaySize 480 270# (In millimeters) makes DPI 100
DisplaySize 400 225# (In millimeters) makes DPI 120
DisplaySize 384 216# (In millimeters) makes DPI 125
DisplaySize 320 180# (In millimeters) makes DPI 150

alejandro@localhost:~> cvt 1360 768

1360x768 59.80 Hz (CVT) hsync: 47.72 kHz; pclk: 84.75 MHz

Modeline “1360x768_60.00” 84.75 1360 1432 1568 1776 768 771 781 798 -hsync +vsync

But now I’m little bit confused since it was added more information to what Ray wrote.

I’m trying to fix my unreadable center-texts of all the windows my Leap 15.3 XFCE system got after the Nvidia drivers were installed. This is the link of my post, so you can see the screenshot I took:

Thanks in advance!

To get an DPI you need to know your device pixel ratio(DPR), you can check it here: screen resolution test
If your DPR if 1 then your DPI is about 96, if it’s 2 then you need to double it and so on…

Respectful manufacturers put the exact sizes of monitor in specs of the monitor.

Dividing the horizontal and vertical resolutions (pixel counts) by corresponding sizes of the monitor will give the actual DPI. (To be fully correct, it might be needed to add one inter-pixel gap size (size of dark separator) to monitor’s sizes before division, but this is a negligible quantity). Use inches, not mm.

The two sizes of pixel are thus obtained. They often differ by 1 - 5 %.

I use this method in KDE’s settings when needed. I take the average of horizontal and vertical sizes, and submit this number to KDE which doesn’t know that those two DPIs can be different and for this reason takes in only one DPI.