LM19.0 & ultra-wide monitors (2560x1080) [solved - after a fashion]

[AndyMH]

Note that I directed another user to this thread

I had noticed, you beat me to it

[AndyMH]

Booted the LM19 laptop off an 18.3 USB stick and the highest resolution 18.3 would give was 1920x1080. It wouldn't boot off USB when in the docking station and had to boot it on its own then connect the ultra-wide monitor and then cycle through the display modes with Fn+F7 to get to the monitor on its own.

So an 18.3 live CD/USB will only give a max of 1920x1080 and it is only AFTER installation that it will give you higher resolutions.

One final issue I've found is that when booting from cold:

Thinkpad splash screen appears [press enter to get into BIOS]
Then the screen blanks but the lower third is 'snow'.
Then the LM logo and then pwd screen.

This 'snow' doesn't appear if you do a restart as opposed to a cold boot (and it doesn't happen at all in 18.3).

A minor annoyance, but is there anything in grub that can be edited to stop this?

[gm10]

Sounds to me like an issue with that device after all then, no?

As far as kernel parameters go, you can supply a custom EDID, that should take care of it I assume:

Code: Select all

	drm.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>]
			Broken monitors, graphic adapters, KVMs and EDIDless
			panels may send no or incorrect EDID data sets.
			This parameter allows to specify an EDID data sets
			in the /lib/firmware directory that are used instead.
			Generic built-in EDID data sets are used, if one of
			edid/1024x768.bin, edid/1280x1024.bin,
			edid/1680x1050.bin, or edid/1920x1080.bin is given
			and no file with the same name exists. Details and
			instructions how to build your own EDID data are
			available in Documentation/EDID/HOWTO.txt. An EDID
			data set will only be used for a particular connector,
			if its name and a colon are prepended to the EDID
			name. Each connector may use a unique EDID data
			set by separating the files with a comma.  An EDID
			data set with no connector name will be used for
			any connectors not explicitly specified.

[AndyMH]

Struggling now!

Looked at https://wiki.archlinux.org/index.php/ke ... de_setting, generated an edid file for the monitor using get-edid and put it in /usr/lib/firmware.

I need to put drm_kms_helper.edid_firmware=HDMI-2:edid/LGultrawide.bin somewhere, but where and how?

[gm10]

Struggling now!

Looked at https://wiki.archlinux.org/index.php/ke ... de_setting, generated an edid file for the monitor using get-edid and put it in /usr/lib/firmware.

I need to put drm_kms_helper.edid_firmware=HDMI-2:edid/LGultrawide.bin somewhere, but where and how?

Into /etc/default/grub, add it to the list of parameters under GRUB_CMDLINE_LINUX_DEFAULT.

Note that you'll either have to move the file to /usr/lib/firmware/edid/ or remove the edid subdirectory from edid/LGultrawide.bin, as you wrote it it's inconsistent.

Also for current kernels the module to use is drm.edid_firmware as I quoted above, drm_kms_helper.edid_firmware you're using is deprecated (at least on my kernel, check modinfo drm_kms_helper on yours).

[AndyMH]

Thanks for that I'll be trying it, but might be a little while.

Decided to go ahead and install LM19 on my daily driver and run into problems with crossover. It works perfectly on my second T430 under LM19 but not on the daily driver. I've got one program, home designer (a 3d home/house design tool), where the 3d output is fine either on the laptop screen or ultrawide monitor. On the daily driver, fine on the laptop screen but garbage on the ultra-wide. Office 2013 also playing up. I've got three 'must haves' all tested on the second T430 - virtual box, crossover and evolution (email). So to start running into problems with the new install is frustrating to say the least, grrrrrrh....

Thankfully retired (most of the time), but guess what I'll be doing all day tomorrow.

[NeroR]

...

Code: Select all

[SeatDefaults]
user-session=cinnamon
display-setup-script=/home/andy/LGmonitor.bsh

...

Maybe this will also help me with my problem (Fix resolution (avoid 4K))!

Note: [SeatDefaults] is deprecated and [Seat:*] should be used instead.
See The Light Display Manager (LightDM) / Configuration, ubuntu wiki - LightDM / Configuration or lightdm/common/configuration.c and lightdm/tests/scripts/seatdefaults-still-supported.conf.

You are using a user-located config-script (/home/andy/LGmonitor.bsh) in a system-wide configuration. This is maybe not the very best structure.
It's maybe also not the best way, to directly modify a config-file of the distribution (70-linuxmint.conf) because this might cause problems on upgrade. Maybe it might be better to create your own config-file, e.g. 71-andy.conf in the directory /etc/lightdm/lightdm.conf.d; I would also move the .bsh-script to this place.

[AndyMH]

You are using a user-located config-script...

Already picked up on some of this, now upgrading my daily driver from 18.3 to 19.0 and I've put the bash script in /usr/bin specifically because if I do a backup, either as an image or with timeshift I want that in the backup.

Thanks for the hints and links, will look at when I've got a bit more time. At the moment fighting with python - why doesn't pip work when it did on 18.3 (and I've got it working on another LM19 PC) and why am I getting an error in my python script when it was fine under 18.3. All this python 2.7. But those will be new threads if I can't resolve it.

[AndyMH]

As a final note on this subject, having got LM19 on the daily driver to a point where it was worth saving, I did an image backup. My tool of choice is redo, now this is old (no longer supported) and based on ubuntu 12.04. Booted up from CD and there it was - 2560x1080 resolution present automatically. Now if an OS released in 2012 can do this properly....

So this is definitely a bug in LM19.

[gm10]

So this is definitely a bug in LM19.

Would you have a /var/log/Xorg.0.log from before applying your fix by the way? It's weird I never asked for one, I think we got side-tracked with the device discussion.

[AndyMH]

Good idea! Short answer no, but it wouldn't be too difficult to undo the fixes on my spare T430. Had a quick look at the current log - bit too big to post - 67kb, nearly 800 lines. From the quick look, it would appear that it's not picking up the right modelines from the monitor, max is 1920x1080, but will need to compare the edid in the log with what I got from get-edid.

Once I've finished setting up LM19 on the daily driver I'll have another look, but likely to be a few days:

• How does the edid in the log compare to the edid extracted with get-edid?

• What differences in the log between an un-fixed T430 and a fixed T430 (the daily driver)?

Is there a guide to the contents of Xorg.0.log, most appears self-evident from inspection, but pointers would be helpful?

And if I've not said it already, a big thank you for all the help you've provided me with on this

[gm10]

Is there a guide to the contents of Xorg.0.log, most appears self-evident from inspection, but pointers would be helpful?

Probably, but I don't have one. Tried a quick google and found this useful wiki page instead:
https://wiki.ubuntu.com/X/Troubleshooti ... _available

I'm mainly wondering if you've got DDC failures comparable to the ones in the example there in your logs. There must be a reason it isn't getting all the modes if the EDID itself has them, as you confirmed it does.

[AndyMH]

Thanks, very useful link.

[AndyMH]

It's a kernel problem!

Posted a 'bug' on github and someone suggested that upgrading from 4.15 to 4.19 might fix the problem, so downloaded ukuu and installed 4.19. Booted up okay but no joy on the monitor resolution, max it would give me on the ultrawide was 1920x1080. So no change from a 4.15 kernel.

This got me thinking, I was running LM18.3 on a 4.4 kernel, so I downloaded 4.4.162, booted into grub to select and lo and behold 2560x1080 resolution.

So, in summary, LM19 with a kernel 4.15+ will not recognise the correct resolutions on my ultrawide monitor, but LM19 with a 4.4 kernel will.

Why we have this behaviour - I've no idea. I've got xorg logs with and without the manual fix (4.15 kernel) and for kernel 4.4, but not sure that this will shed any light on the matter.

NOTE - I did this on my test T430, not the daily driver. I would not recommend booting potentially unstable kernels on a machine that you can't afford to bork.

Now to see what happens with 4.13....

Edit - no joy with 4.13.16, highest res is as 4.15+, 1920x1080. So the problem occurred after 4.4. Now what do I lose if I regress the daily driver back to 4.4, it is a LTS release?

Edit2 - subjectively I think the system boots a lot quicker with a 4.4 kernel.

[gm10]

Kernel driver after all? Interesting. In the other thread he said he'd had the problem since LM18.2, which released with 4.8 kernels. You'd think somebody had properly reported this since.

[AndyMH]

since LM18.2, which released with 4.8 kernels

I started off with 17.3 and then did a clean install of 18.0 with a 4.4 kernel (as it came 'out of the box') and while I upgraded to 18.x never went for a later kernel. Since I'm playing on the test T430, I'll see what happens with 4.8 and report back.

All is not quite "hunky-dory" with LM19+4.4. Normally T430 sits in docking station, press start and it uses the ultrawide, but just background piccy, move mouse and login appears, login and sometimes laptop appears to go into suspend, have to hit power button to get normal screen. Still working on this.

[AndyMH]

The problem has been there since kernel 4.6. Using UKUU (only just found it, do like it) Installed the latest version for each kernel and rebooted each time.

4.5.7 is the last kernel that found the ultra-wide monitor and correctly set it at 2560x1080.

Everything since will only give a maximum resolution of 1920x1080.

I'm going to open a new topic on this - it may just be my setup T430 + LG 25UM58 monitor or more general and I suspect there aren't that many of us using ultrawide monitors (yet).

Thanks again for all your support on this one. Where do you report a kernel bug?

[gm10]

Where do you report a kernel bug?

At Ubuntu and kernel.org. Here's an overview:
https://wiki.ubuntu.com/Kernel/Bugs

[AndyMH]

Thanks for that, I'll raise a bug report, content dependent on the responses to my latest topic post.

[AndyMH]

Don't know if this provides any further clues - comparison of the xorg logs for working and non working setups.

Same T430, i5-3320M, intel integrated GPU, sat in a docking station driving an LG ultra-wide through a displayport to the monitor. Running LM19 cinnamon. Booted up with lid closed so that the system defaults to the external ultra-wide monitor (which is my normal mode of operation).

Kernel 4.4.0-162 = GOOD
Kernel 4.15.0-138 = BAD

X.Org X Server 1.19.6

This is common:

Code: Select all

[     7.588] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[     7.589] (==) No Layout section.  Using the first Screen section.
[     7.589] (==) No screen section available. Using defaults.
[     7.589] (**) |-->Screen "Default Screen Section" (0)
[     7.589] (**) |   |-->Monitor "<default monitor>"
[     7.589] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.

Still common

Code: Select all

[     7.147] (II) glamor: EGL version 1.4 (DRI2):
[     7.158] (II) modeset(0): glamor initialized
[     7.686] (II) modeset(0): Output LVDS-1 has no monitor section
[     7.690] (II) modeset(0): Output VGA-1 has no monitor section
[     7.904] (II) modeset(0): Output HDMI-1 has no monitor section
[     7.904] (II) modeset(0): Output DP-1 has no monitor section
[     7.989] (II) modeset(0): Output HDMI-2 has no monitor section
[     7.998] (II) modeset(0): Output HDMI-3 has no monitor section
[     8.077] (II) modeset(0): Output DP-2 has no monitor section
[     8.077] (II) modeset(0): Output DP-3 has no monitor section

Does EDID output for LVDS-1 - common

Then reads EDID for ultra-wide

[ 8.380] (II) modeset(0): First detailed timing is preferred mode - common

Also common - note it is picking up the 2560x1080 res in both, it is followed by the same info for a number of different resolutions.

Code: Select all

[     8.380] (II) modeset(0): Supported detailed timing:
[     8.380] (II) modeset(0): clock: 185.6 MHz   Image Size:  673 x 284 mm
[     8.380] (II) modeset(0): h_active: 2560  h_sync: 2624  h_sync_end 2688 h_blank_end 2784 h_border: 0
[     8.380] (II) modeset(0): v_active: 1080  v_sync: 1083  v_sync_end 1093 v_blanking: 1111 v_border: 0

Shows the EDID in hex - same for both, and the same as the EDID I pulled from the monitor with get-edid. Then the first difference:

GOOD - it picks up the modeline for 2560x1080

Code: Select all

[     7.265] (II) modeset(0): Printing probed modes for output HDMI-2
[     7.265] (II) modeset(0): Modeline "2560x1080"x60.0  185.58  2560 2624 2688 2784  1080 1083 1093 1111 -hsync -vsync (66.7 kHz eP)
[     7.265] (II) modeset(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)

BAD - no modeline for 2560x1080

Code: Select all

[     8.381] (II) modeset(0): Printing probed modes for output HDMI-2
[     8.381] (II) modeset(0): Modeline "1920x1080"x60.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[     8.381] (II) modeset(0): Modeline "1920x1080"x50.0  148.50  1920 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)

Next, having been through all the other ports (not connected).

GOOD

Code: Select all

[     7.292] (II) modeset(0): Using spanning desktop for initial modes
[     7.292] (II) modeset(0): Output LVDS-1 using initial mode 1366x768 +0+0
[     7.292] (II) modeset(0): Output HDMI-2 using initial mode 2560x1080 +1366+0

BAD

Code: Select all

[     8.469] (II) modeset(0): Using fuzzy aspect match for initial modes
[     8.469] (II) modeset(0): Output LVDS-1 using initial mode 1024x768 +0+0
[     8.469] (II) modeset(0): Output HDMI-2 using initial mode 1024x768 +0+0

Why is the good one spanning and the bad one fuzzy?

Then it goes through what look like the usb ports picking up the MS nano transceiver for keyboard and mouse, trackpoint, touchpad, etc. = Common.

Next bit on the monitors is almost common.

For the laptop screen:

Code: Select all

[    17.876] (II) modeset(0): EDID vendor "LGD", prod id 821
[    17.876] (II) modeset(0): Printing DDC gathered Modelines:
[    17.876] (II) modeset(0): Modeline "1366x768"x0.0   69.30  1366 1398 1430 1470  768 771 776 786 -hsync -vsync (47.1 kHz eP)

This is repeated 2x for GOOD and 5x for BAD

After the first in GOOD:

Code: Select all

[    17.430] (II) modeset(0): Allocate new frame buffer 2560x1080 stride

After the fourth in BAD:

Code: Select all

[    19.675] (II) modeset(0): Allocate new frame buffer 1920x1080 stride

Then it prints the fifth 'printing DDC...' in BAD

It then goes to the modelines for the ultra-wide, printing out all the modelines. For both they are the same with the first modeline 2560x1080.

Code: Select all

[    34.206] (II) modeset(0): Printing DDC gathered Modelines:
[    34.206] (II) modeset(0): Modeline "2560x1080"x0.0  185.58  2560 2624 2688 2784  1080 1083 1093 1111 -hsync -vsync (66.7 kHz eP)
[    34.206] (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
[    34.206] (II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2008 2052 2200  1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
[    34.206] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 1650  720 725 730 750 +hsync +vsync (45.0 kHz e)
[    34.206] (II) modeset(0): Modeline "720x480"x0.0   27.00  720 736 798 858  480 489 495 525 -hsync -vsync (31.5 kHz e)
[    34.206] (II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
[    34.206] (II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
[    34.206] (II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
[    34.206] (II) modeset(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
[    34.206] (II) modeset(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
[    34.206] (II) modeset(0): Modeline "1024x768"x0.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
[    34.206] (II) modeset(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
[    34.206] (II) modeset(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
[    34.206] (II) modeset(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[    34.206] (II) modeset(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[    34.206] (II) modeset(0): Modeline "1280x720"x60.0   74.48  1280 1336 1472 1664  720 721 724 746 -hsync +vsync (44.8 kHz e)
[    34.206] (II) modeset(0): Modeline "1600x900"x60.0  119.00  1600 1696 1864 2128  900 901 904 932 -hsync +vsync (55.9 kHz e)
[    34.206] (II) modeset(0): Modeline "1680x1050"x0.0  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
[    34.206] (II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2448 2492 2640  1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e)
[    34.206] (II) modeset(0): Modeline "720x576"x0.0   27.00  720 732 796 864  576 581 586 625 -hsync -vsync (31.2 kHz e)
[    34.206] (II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2448 2492 2640  1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
[    34.206] (II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1720 1760 1980  720 725 730 750 +hsync +vsync (37.5 kHz e)

For BAD the printing modelines section for the ultra-wide is repeated once. For GOOD it is repeated 32x???

End of file.

All I can see here is that both are reading the monitor EDID correctly, both know that there is a modeline for 2560x1080, but kernel 4.15 is ignoring it when 'printing probed modes'.