Created attachment 137515 [details] dmesg output with drm.debug=0xe The TB3 LG 5K Ultrafine display is not detected correctly when connected to a Thinkpad X1C5 (with Intel HD Graphics 620) using USB-C. The monitor is detected as two displays, with DP-1 having 16:9 modes up to 4096x2304 and DP-2 having a single 2560x2880 mode. After manually creating a new mode for DP-1 with identical settings to the DP-2 mode, tiled display works, but the DP-2 tile is desynced from the DP-1 tile (the top of the logical display appears in the middle of the physical display, which wraps around top-to-bottom). This is possibly related to bug 97244 (in particular this is the monitor mentioned in the last comment as only working with Macs). I don't know if it's the same issue, so I made a new bug.
Created attachment 137516 [details] Output of `monitor-get-edid | edid-decode`
Created attachment 137517 [details] Raw EDID info
Created attachment 137518 [details] Output of `xrandr --verbose`
This looks like the tiled display with DP SST mode and not exposing the tile property for SST case might be the cause of tiles not getting detected properly and having to manually create an identical mode for DP-1. We are working on patches to add the tile property for SST. Just to confirm the system configuration, you have two USb-C/TBT cables between laptop and the monitor? Manasi
The display is connected by a single cable (the one that came with the monitor) carrying both DP signals, connected to one of the USB-C/TB ports on the left side of the X1C.
Created attachment 137705 [details] [review] fix patch
Thunderbolt 3 can drive 2 DP using only one cable. Henry can you apply this https://bugs.freedesktop.org/attachment.cgi?id=137705 and test again? And share the new dmesg output. Thanks
Sure! Just to check, I should be applying this patch to the drm-tip branch here: https://cgit.freedesktop.org/drm-tip/log/ ?
Yes, drm-tip branch.
Created attachment 137758 [details] dmesg output of patched kernel with drm.debug=0xe The monitor is connected around 120s after boot.
Created attachment 137759 [details] Output of `xrandr --verbose` with patched kernel
I see that now, DP 1 is showing 3840x2160 and DP 2 is 2560x2880 with TILE property. Although I dont know what all these TILE bits are TILE: 1 1 2 1 1 0 2560 2880 Does it fix the display at all? Manasi
I guess it did not worked, by some reason the first tile(DP-1) is not exporting the tile in EDID, both should do it with just different location value. Try change the resolution of the DP-1 to 2560x2880, this way both DP/tiles would render half of a 5K display.
After changing the DP-1 mode to the tile size, I get the DP-1 tile displaying correctly, but the DP-2 tile has new and different corruption. When I move a terminal window onto the DP-2 tile, it looks like the "solitare effect" (http://www.geocities.ws/petessolitaireclan/solitaire5.JPG), where as I move the window around, it's drawn on top of the previous location. This seems really weird since I'm not sure what could cause that kind of corruption.
So changing the DP-1 resolution to 2560x2880 made the tile information to show up in DP-1, nice. I guess now you need to do a "xrandr --setmonitor" to combine both DPs into a 5K monitor. Take a look here: https://keithp.com/blogs/MST-monitors/ Sorry we still don't have a running setup with a tiled monitor to test this.
Created attachment 137782 [details] DELL_UP2715_dmesg_xrandr Sorry for predating this bugreport, I'm dealing with related issues on my 5k Dell UP2715K that is quite similar internally (two tiles 2560x2880, dual DP, SST). Except of that it's connected via two DP cables. With this patch the tile properties are exposed properly in xrandr: > DP1 connected 2560x2880+2560+0 (0x16a) normal (normal left inverted right x axis y axis) 600mm x 340mm > TILE: 1 1 2 1 1 0 2560 2880 > DP2 connected primary 2560x2880+0+0 (0x16a) normal (normal left inverted right x axis y axis) 600mm x 340mm > TILE: 1 1 2 1 0 0 2560 2880 but that's the only difference. The image is still broken in pieces as before (see bug 97244 for the picture).
Tomas Bzatek did you setup xrandr after apply the patch? See here: https://github.com/i3/i3/issues/1799#issuecomment-233900476
Is there a possible reason why applying that patch would cause *increased* display corruption? I guess I am comparing 4.16.0-rc3-sst-tile-patch (drm-tip+patch) to 4.15.6-300.fc27.x86_64 (the Fedora kernel), so maybe I should test drm-tip without the patch to see if changes between 4.15 and drm-tip are the cause. On the stock kernel, I get offset displays, as in the photo of the other bug. Setting up an xrandr monitor doesn't seem to make a difference.
(In reply to Jose Roberto de Souza from comment #17) > Tomas Bzatek did you setup xrandr after apply the patch? > See here: https://github.com/i3/i3/issues/1799#issuecomment-233900476 I did something similar and I can see the newly created monitor in the `xrandr --listmonitors` output. No difference in mode setting and no change from the windowmanager side either. I understand the WM needs to be aware of this logical monitor setup but would it make a difference in KMS, i.e. would it magically cause the outputs to get synchronized? Also, is there a difference in DDX driver used? I'm using the legacy intel driver as modesetting+glamor is noticeably slower. I've tried both anyway with exactly the same results (tiles out of sync), the only difference was in display output naming. That said I'm still seeing hardware sync issues where the panel is perhaps unable to find and synchronize the first scanlines of the frame. It's probably specific to the panel controller with perhaps only little delay tolerance between the inputs. Other panels may allow more tolerance at the expense of larger input lag.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open is issue still exists.
Hi, I just got myself a Ultrafine 5K and I am trying to work out how to use it with my XPS 13 9360. I am having the same issue as above (the top of the second half of the screen show up in the middle of the screen). It shows up as two separate displays (DP1 and DP2) on my laptop--I could use DP1 to get resolution up to 4096x2032 and DP2 reported one resolution of 2560x2880. I added the 2560x2880 mode to DP1 and `xrandr --setmonitor ...` in order to create the monitor. My i3status bar spanned across the display so I believe the configuration on i3's part is not the problem. I still have a shift in the middle of the display, where the i3bar shows up in the middle of the screen. I had patched kernel 4.18.5 with the patch above, and it shows the TILE property but not on the first display. I am out of methods to try--seems like people here had the same problem, did anyone manage to get this fixed? Charles
I should add that I tried it with the latest drm-tip branch as well (with the patch applied.)
(In reply to Charles Yoon from comment #23) > I should add that I tried it with the latest drm-tip branch as well (with > the patch applied.) Can you send dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.
Charles, can you attach the latest dmesg logs that you have tested with latest drm-tip branch? That will help to speed up the investigation.
(In reply to Lakshmi from comment #25) > Charles, can you attach the latest dmesg logs that you have tested with > latest drm-tip branch? That will help to speed up the investigation. Yes, sorry for the late reply--I am compiling the latest version at the moment and will be able to provide you with the outputs soon.
Created attachment 141584 [details] dmesg output from drm-tip w/ patch
I've just attached the dmesg output. I also tried to do the manual tile by running: $ xrandr --addmode DP-1 2560x2880 $ xrandr --output DP-1 --mode 2560x2880 --right-of eDP-1 --output DP-2 --mode 2560x2880 --right-of DP-1 which resulted in the same behavior as above.
Jose, any advise here?
This is the same bug as https://bugs.freedesktop.org/show_bug.cgi?id=97244 And for this to work we need the transcoder port sync feature that is not enabled yet and the patch attached here.
*** This bug has been marked as a duplicate of bug 97244 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.