drm: expose the connector TILE property#2034
Open
algesten wants to merge 1 commit into
Open
Conversation
The first generation of 5K monitors (LG UltraFine 5K, Dell UP2715K, mid-2010s) couldn't fit 5120x2880@60 down a single DP 1.2 cable and instead carry the image as two streams, one per tile half. Each half presents as its own DRM connector, with a DisplayID Tile Topology block in its EDID describing where it sits in the monitor. The kernel parses that block and exposes the result as the `TILE` immutable blob, formatted as eight ':'-delimited decimals: group_id:flags:num_h_tiles:num_v_tiles:loc_h:loc_v:tile_w:tile_h. Newer 5K panels carry the image on a single cable using DSC over DP 1.4, or uncompressed over DP 2.1 UHBR. `DrmDevice::tile_info()` reads the blob, parses it into a new `backend::drm::TileInfo` struct, and returns `None` for connectors without one. Compositors can use the shared `group_id` to identify connectors that belong to the same physical monitor. The kernel's `flags` field is parsed and discarded. It isn't documented and Mutter ignores it. AI-generated: This code was co-authored with Claude (Anthropic).
Member
|
Hmm. Exposing the TILE property is definitely not wrong, as we need this information to correctly handle this case. I just wonder if a pure drm-helper in smithay is the right approach or whether we could provide more abstractions for this in smithay and if we perhaps even should.
Either way thanks for working on this. We might just need a little more design work first. Luckily the code you wrote so far for smithay at least is very universally applicable and just needs to be moved around at worst. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Disclosure: I have done this PR using Claude Code. Whilst I am well versed in Rust (I wrote ureq among other), I know very little about the graphics stack in Linux. I had Claude teach me what I need to know to fix my problem.
I use a LG UltraFine 5K that is about 8 years old and uses tiled DP 1.2 to render 5K. I just now installed PopOS/COSMIC and it doesn't drive my monitor correctly. The monitor is Thunderbolt only, and connected to a Maple Ridge PCIe card that in turn takes two DP cables from my NVIDIA card. I believe the problem is described here (pop-os/cosmic-comp#2295)
The monitor presents itself as two DP streams with two EDID. In the EDID there is a TILE property, which is available in drm, but currently not possible to read from Smithay.
This TILE property contains the necessary info to understand that it's a tiled situation and the DP streams should be rendered to as if two halves of the same screen.
The PR adds
backend::drm::TileInfoandDrmDevice::tile_info(), along with the ASCII-blob parser for the kernel format. It is what is needed from Smithay.I got the full thing working in cosmic-comp locally.
group_id, positions(0,0)and(1,0)in a 2x1 grid, tile size 2560x2880.