Page 1 of 4

Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Tue Jul 01, 2025 9:14 am
by operadude
Coming to you from my new testing rig (dedicated, stand-alone machine for testing stuff) :exclamation:

All is good, except for screwy s-dpi, s-size & s-diag for this machine. Need to change them!

This monitor (1920x1080, 60Hz) has 3 HDMI-in ports. I use one of them for this testing rig, another one for my daily driver (Gigabyte machine-- running now), and a streamer.

Everything was perfectly fine before installing Nvidia drivers, which I tried once before, but rolled-back. Tried again today, and got the same results, but I managed to correct some problems. Still, I see that the s-dpi, s-size & s-diag are set INCORRECTLY for this testing rig.

Question:
How can I manually and permanently change them?

Here's what they should be (currently on my Gigabyte machine):
s-dpi: 96
s-size: 509x286 mm
s-diag: 584mm

Here's what they are on this testing rig:
s-dpi: 305
s-size: 160x90 mm
s-diag: 184mm

Last, but not least, here's the QSI from the testing rig:

Code: Select all

Snapshot created on: 20250617_1407
System:
  Kernel: 6.1.0-37-amd64 [6.1.140-1] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.1.0-37-amd64 root=UUID=<filter> ro quiet splash
  Desktop: KDE Plasma v: 5.27.5 info: plank wm: kwin_x11 vt: 7 dm: SDDM Distro: MX-23.6_x64
    Libretto October 13 2023 base: Debian GNU/Linux 12 (bookworm)
Machine:
  Type: Desktop System: ASUS product: All Series v: N/A serial: <superuser required>
  Mobo: ASUSTeK model: H81M-K v: Rev X.0x serial: <superuser required> UEFI: American Megatrends
    v: 1101 date: 03/09/2015
CPU:
  Info: model: Intel Core i5-4690 bits: 64 type: MCP arch: Haswell gen: core 4 level: v3
    note: check built: 2013-15 process: Intel 22nm family: 6 model-id: 0x3C (60) stepping: 3
    microcode: 0x28
  Topology: cpus: 1x cores: 4 smt: <unsupported> cache: L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB
    L2: 1024 KiB desc: 4x256 KiB L3: 6 MiB desc: 1x6 MiB
  Speed (MHz): avg: 825 high: 900 min/max: 800/3900 scaling: driver: intel_cpufreq
    governor: ondemand cores: 1: 800 2: 900 3: 800 4: 800 bogomips: 27935
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: indirect_target_selection status: Not affected
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
  Type: mds mitigation: Clear CPU buffers; SMT disabled
  Type: meltdown mitigation: PTI
  Type: mmio_stale_data status: Unknown: No mitigations
  Type: reg_file_data_sampling status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Not affected
  Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Retpolines; IBPB: conditional; IBRS_FW; STIBP: disabled; RSB
    filling; PBRSB-eIBRS: Not affected; BHI: Not affected
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: NVIDIA GK107 [GeForce GT 740] vendor: ASUSTeK driver: nvidia v: 470.256.02 non-free:
    series: 470.xx+ status: legacy-active (EOL~2023/24) arch: Kepler code: GKxxx process: TSMC 28nm
    built: 2012-18 pcie: gen: 2 speed: 5 GT/s lanes: 16 bus-ID: 01:00.0 chip-ID: 10de:0fc8
    class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv gpu: nvidia display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 305 s-size: 160x90mm (6.30x3.54") s-diag: 184mm (7.23")
  Monitor-1: HDMI-0 res: 1920x1080 hz: 60 dpi: 305 size: 160x90mm (6.3x3.54") diag: 184mm (7.23")
    modes: N/A
  API: OpenGL v: 4.6.0 NVIDIA 470.256.02 renderer: NVIDIA GeForce GT 740/PCIe/SSE2
    direct-render: Yes
Audio:
  Device-1: Intel 8 Series/C220 Series High Definition Audio vendor: ASUSTeK 8
    driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:8c20 class-ID: 0403
  Device-2: NVIDIA GK107 HDMI Audio vendor: ASUSTeK driver: snd_hda_intel v: kernel pcie: gen: 2
    speed: 5 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 10de:0e1b class-ID: 0403
  API: ALSA v: k6.1.0-37-amd64 status: kernel-api tools: alsamixer,amixer
  Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse status: active
    2: wireplumber status: active 3: pipewire-alsa type: plugin 4: pw-jack type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet vendor: ASUSTeK H81M-C
    driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: d000 bus-ID: 03:00.0
    chip-ID: 10ec:8168 class-ID: 0200
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
  IF-ID-1: docker0 state: down mac: <filter>
Drives:
  Local Storage: total: 1.02 TiB used: 74.09 GiB (7.1%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/sda maj-min: 8:0 model: SATA SSD size: 111.79 GiB block-size: physical: 512 B
    logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 61.3 scheme: GPT
  ID-2: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST1000DM003-1ER162 size: 931.51 GiB
    block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 serial: <filter>
    rev: CC45 scheme: GPT
Partition:
  ID-1: / raw-size: 111.54 GiB size: 109.23 GiB (97.93%) used: 29.23 GiB (26.8%) fs: ext4
    dev: /dev/sda2 maj-min: 8:2
  ID-2: /boot/efi raw-size: 256 MiB size: 252 MiB (98.46%) used: 274 KiB (0.1%) fs: vfat
    dev: /dev/sda1 maj-min: 8:1
Swap:
  Kernel: swappiness: 15 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: file size: 3 GiB used: 0 KiB (0.0%) priority: -2 file: /swap/swap
Sensors:
  System Temperatures: cpu: 37.0 C mobo: N/A gpu: nvidia temp: 40 C
  Fan Speeds (RPM): N/A gpu: nvidia fan: 20%
Repos:
  Packages: pm: dpkg pkgs: 3124 libs: 1595 tools: apt,apt-get,aptitude,nala pm: rpm pkgs: 0
    pm: flatpak pkgs: 0
  No active apt repos in: /etc/apt/sources.list
  Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
    1: deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/debian.list
    1: deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
    2: deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
  Active apt repos in: /etc/apt/sources.list.d/mx.list
    1: deb https://mxrepo.com/mx/repo/ bookworm main non-free
    2: deb https://mxrepo.com/mx/repo/ bookworm ahs
  No active apt repos in: /etc/apt/sources.list.d/skype-stable.list
Info:
  Processes: 199 Uptime: 15m wakeups: 1 Memory: 7.69 GiB used: 1.5 GiB (19.5%) Init: SysVinit
  v: 3.06 runlevel: 5 default: graphical tool: systemctl Compilers: gcc: 12.2.0 alt: 12
  Client: shell wrapper v: 5.2.15-release inxi: 3.3.26
Boot Mode: UEFI
Just to give you an idea of what's going on, here's a pic:

Image

And, one more:

Image

EDIT/ADDENDUM:

This might be the best pic: when I select the "Whisker Menu" (not sure if that's what it's called in KDE), it takes come a HUGE portion of the screen. Other windows are also way-too-big!!! Anyway, a picture is worth a thousand words, so, here you go:

Image

:crossfingers:

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Tue Jul 01, 2025 10:01 am
by operadude
Well, that was weird :exclamation: :eek: :exclamation:

So, I had turned-off "compositing", which seemed to solve some of the window-sizes problem; although, some of the windows remained huge, especially icons on the desktop, items in the taskbar, some menu windows, etc.

Then, I thought, for proper diagnosis, I should really re-enable the "compositing" feature, so as not to contaminate the diagnosis process. After Reboot, here are what the pics look like:

Image

Image

So, looks like everything is OK. BUT....

Strangely, the QSI still shows the wrong dimensions for s-dpi, s-size & s-diag :exclamation:

Code: Select all

Graphics:
  Device-1: NVIDIA GK107 [GeForce GT 740] vendor: ASUSTeK driver: nvidia v: 470.256.02 non-free:
    series: 470.xx+ status: legacy-active (EOL~2023/24) arch: Kepler code: GKxxx process: TSMC 28nm
    built: 2012-18 pcie: gen: 2 speed: 5 GT/s lanes: 16 bus-ID: 01:00.0 chip-ID: 10de:0fc8
    class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 with: Xwayland v: 22.1.9 compositor: kwin_x11 driver: X:
    loaded: nvidia unloaded: fbdev,modesetting,nouveau,vesa alternate: nv gpu: nvidia display-ID: :0
    screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 305 s-size: 160x90mm (6.30x3.54") s-diag: 184mm (7.23")
  Monitor-1: HDMI-0 res: 1920x1080 hz: 60 dpi: 305 size: 160x90mm (6.3x3.54") diag: 184mm (7.23")
    modes: N/A
  API: OpenGL v: 4.6.0 NVIDIA 470.256.02 renderer: NVIDIA GeForce GT 740/PCIe/SSE2
    direct-render: Yes
At this point, I will leave it alone, unless someone with a higher pay-grade than me says I should change it :p

Please let me know your thoughts :exclamation:

EDIT/ADDENDUM:

I'm wondering if the post in the link below, and code I snipped from there, might have something to do with what happened to my system:

viewtopic.php?p=793301#p793301

I did not use the code below, but I did turn-off compositing (xrandr?) and re-start:

Code: Select all

xrandr --output HDMI-0 --off ; sleep 1 ; xrandr --output HDMI-0 --primary --mode 1920x1080 --rate 60
So, maybe my disabling and then re-enabling Compositing had the same effect as the post in the link above describes?

Also, let me know if you think I should try to manually change the s-dpi, s-size, & s-diag, which still seem to have the WRONG dimensions, as shown in the QSI :exclamation: :confused: :exclamation:

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Tue Jul 01, 2025 12:13 pm
by operadude
Follow-Up:

Upon "cold" boot, the LightDM login screen is HUGE-- cannot see the complete fields for Username and Password. Not a problem, since I know my password by heart!

BUT, after logon, everything looks OK.

Maybe I SHOULD try to change those parameters?

Or, "If it aint (mostly) broke, don't fix it" ?

:confused:

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Tue Jul 01, 2025 2:01 pm
by CharlesV
Were your settings manually set this way or did it install with the nvidia drivers this way?

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Tue Jul 01, 2025 2:29 pm
by operadude
CharlesV wrote: Tue Jul 01, 2025 2:01 pm Were your settings manually set this way or did it install with the nvidia drivers this way?
I did nothing, except install the Nvidia drivers.

I'm not sure what the settings were before installing the Nvidia drivers.

Reminds me of something I think you recommended on another post:

During Backup, get a copy of your QSI :exclamation:

Obviously, I didn't do that!

:bagoverhead:

ADDENDUM:

Thanks CharlesV for the reply.

I will check back tomorrow..."Shutting down for system halt NOW" ;)

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Tue Jul 01, 2025 3:05 pm
by CharlesV
This sounds like maybe rolling back to the opensource driver and seeing what that does might give the needed clue?

That xrandr command looks like it is defining basically a turn off and turn on - waking up the monitor and telling the video to wake up essentially. I dont believe that is an issue.

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Wed Jul 02, 2025 2:40 am
by operadude
CharlesV wrote: Tue Jul 01, 2025 3:05 pm This sounds like maybe rolling back to the opensource driver and seeing what that does might give the needed clue?

That xrandr command looks like it is defining basically a turn off and turn on - waking up the monitor and telling the video to wake up essentially. I dont believe that is an issue.
Yeah, I wasn't sure about the xrandr command, so I DID NOT run it!

Got some rest, and realized that I DO HAVE the old QSI-- via MX-Snapshot :exclamation:, which I took after configuring the sytem; I also made a Live USB, via MX-LUM :exclamation: I will 'Boot from my LUE' ( :eek: ), i.e., boot from the Live USB Environment, and check the QSI from the original state, i.e., before the Nvidia drivers were installed. Will report back with that info.

As it stands, I really do want to keep the Nvidia drivers, as I will be using this testing rig for running AI models (e.g. Ollama) locally; and so, I want the Nvidia/Cuda drivers for that. Also, as of now, the only glitch in the system is the LightDM login screen, which is a bit annoying (HUGE size), but a minor inconvenience.

What is irking me is the fact that the system seems to still think that my monitor has these dimensions: 160x90mm (s-size) & 184mm (s-diag), with 305 dpi. However, it now seems that those dimensions are being used ONLY with LightDM. After logging-on, everything reverts to normal dimensions, and is visually identical to my main rig (on the other HDMI port). Again, I can live with the weird LightDM settings...

Anyway, is there a safe way (without breaking dependencies or the system as a whole), via CLI, to manually change those dimensions: s-dpi, s-size, & s-diag ???

Even if I don't end-up changing them, I would like to know how to do that, via CLI :exclamation:

Thanks again for the reply :exclamation:

Exclamatorily, Yours (I use way too many exclamation points, right?) :exclamation:,

:cool:

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Wed Jul 02, 2025 3:47 am
by operadude
operadude wrote: Tue Jul 01, 2025 2:29 pm
CharlesV wrote: Tue Jul 01, 2025 2:01 pm Were your settings manually set this way or did it install with the nvidia drivers this way?
I did nothing, except install the Nvidia drivers.

I'm not sure what the settings were before installing the Nvidia drivers.

Reminds me of something I think you recommended on another post:

During Backup, get a copy of your QSI :exclamation:

Obviously, I didn't do that!

:bagoverhead:

ADDENDUM:

Thanks CharlesV for the reply.

I will check back tomorrow..."Shutting down for system halt NOW" ;)
CORRECTION ;) :
Sorry about the misquote above ("Shutting down for system halt NOW")

The correct quote is:

"The system is going down for system halt NOW!"

:p

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Wed Jul 02, 2025 10:55 am
by CharlesV
Glad you got some sleep - you look all fired up :-)

So, xrandr can tell you what your hardware is (or .. what it thinks it is), and then you can set params to set the system using it.

The way I have seen it used in this case before is to have lightdm fire off a script that sets the screen res the way you want it.

Here is an example of setting a res for a DVI output in a script.

SetVideoRes.sh

Code: Select all

#!/bin/sh
xrandr --output DVI-0 --primary --mode 1920x1080 

You would have to change to your correct video output, and then save this to your script folder (or desktop etc). Then make it executable.

Code: Select all

chmod a+rx SetVideoRes.sh

Run it and make sure that all is good. ( maybe change the res some if your regular mode is 1920x1080, just to verify all good.)

If all good, then put the script in your /usr/share folder (so it doesnt get blown out).

Then in the /etclightdm folder edit the lightdm.conf file and add the following line at the end of the file

Code: Select all

display-setup-script=/usr/share/SetVideoRes.sh

Next logout or reboot you should have the video res size that your after / specified, at login.

Caveat - I am only about have way through my first cup of coffee ... so double check everything ;-p

Re: Manually Change in CLI: s-dpi, s-size & s-diag

Posted: Wed Jul 02, 2025 12:09 pm
by operadude
@CharlesV :number1:

That looks AWESOME :exclamation:

It looks like it will have to wait until tomorrow to test that all out...

I will let you know how it goes.

I really appreciate the feedback and the detailed/thorough response!

:hug: