enhancement: Implement RandR 1.5 support

[stapelberg]

See http://cgit.freedesktop.org/xorg/proto/randrproto/commit/?id=4109f29861a7066970a2afd079d0fc2c12828bcb for the spec changes.

We should evaluate whether i3 needs to understand the new concept of “monitors” — it is my understanding that we have to add support for it, otherwise we will misdetect tiled 4K displays (using Multistream Transport = MST), such as the Dell UP2414Q, as being multiple monitors instead of just one monitor.

Unfortunately, AFAICT, not a single graphics driver supports RandR 1.5 yet, so ideally we’d find a different way of testing such a scenario. Maybe contacting Dave Airlie or Keith Packard and asking for test data (in which format?) would help.

[acrisci]

Do we need to support both versions?

[Airblader]

therwise we will misdetect tiled 4K displays […] as being multiple monitors instead of just one monitor.

Are you sure? From what I understand it'd be quite the opposite: the user wants to split one physical output into multiple monitors but since we don't support the monitors concept, we keep treating it as one (big) screen. Or am I reading the spec wrong?

Either way, I'm not sure why we should support a concept that has no graphics driver support yet. If we build that feature, we have to maintain code that we probably can't verify. We also keep around dead code that no one can use yet for an unknown amount of time. IMHO, we should build this feature once drivers support it at the earliest, ideally when we see people actually using the concept.

[stapelberg]

Do we need to support both versions?

Not entirely sure if that’s what you mean, but we do need to support RandR < 1.5 and RandR ≥ 1.5 :).

Are you sure? From what I understand it'd be quite the opposite: the user wants to split one physical output into multiple monitors but since we don't support the monitors concept, we keep treating it as one (big) screen. Or am I reading the spec wrong?

I think you’re indeed reading it wrong. Check out http://keithp.com/blogs/MST-monitors/ for more background.

Either way, I'm not sure why we should support a concept that has no graphics driver support yet. If we build that feature, we have to maintain code that we probably can't verify.

That’s why I mentioned that there might be other ways to verify our understanding of the spec.

We also keep around dead code that no one can use yet for an unknown amount of time. IMHO, we should build this feature once drivers support it at the earliest, ideally when we see people actually using the concept.

Yeah, having drivers which support it is obviously a requirement for the code to be useful, but it would be good to have code (almost?) ready when capable drivers are released, so that users don’t have to wait for too long until they can use i3 in such a setup.

[Airblader]

Indeed, that article helped, thanks. So basically what we need to do is

• if RandR >= 1.5 is available, use the Monitor concept and ensure existing setups (with the auto-generated Monitors) don't break.
• if only RandR < 1.5 is available, use the old CRTC information.

That would also mean we don't really keep dead code around. Running RandR 1.5 and being able to do multiscreens should be enough (for now) to make sure our implementation works. Actually being able to run a MST setup depends on the graphics drivers and we would, of course, like to verify it, but for now we don't really need that.

However, how do we want to deal with XCB? We can't really raise the dependency (is RandR 1.5 even supported in the latest XCB release or only in the development version (or not at all yet)?), which would leave us with having to deal with Xlib for RandR 1.5, correct?

[stapelberg]

That would also mean we don't really keep dead code around. Running RandR 1.5 and being able to do multiscreens should be enough (for now) to make sure our implementation works.

That way we could at least verify that things don’t break and that we support the monitor concept per se, yeah.

However, how do we want to deal with XCB? We can't really raise the dependency (is RandR 1.5 even supported in the latest XCB release or only in the development version (or not at all yet)?), which would leave us with having to deal with Xlib for RandR 1.5, correct?

Ugh, indeed. I confused randrproto and xcb-proto when looking at where it’s implemented so far. So, yes, we’d need to first update xcb-proto, then get libxcb rebuilt at least (a new release might not be necessary). We should definitely wait until an xcb version which supports this is available in the major distros.

[stapelberg]

I compiled Xephyr, libXrandr and randrproto from git and have xrandr(1)’s --listmonitors option working. I’ll see if I can come up with the necessary xcb-proto modifications to expose the GetMonitors request to i3.

[stapelberg]

Got a proof-of-concept working (see 74a7adb), will send the necessary patch to the xcb-devel list later.

[Airblader]

Cool!

Unfortunately I can't do xrandr --listmonitors. I'm on the latest everything (Arch) including xorg-xrandr-git and libxrandr / randrproto = 1.5.0. But when I execute the aforementioned command, it tells me my server doesn't support RandR 1.5. What am I missing? Do I need to build xorg-server from source too or something?

[stapelberg]

@Airblader Possibly. If xtrace shows a QueryVersion request with minor=5, then your tool/library is up-to-date. Try using Xephyr.

[stapelberg]

FYI, I posted a patch to the xcb-devel mailing list and expect it to be committed some time next week. Then, we’ll need to make a new xcb-proto release and update distribution packages. At that point it makes sense to turn the proof-of-concept into actual code that’s part of i3.

[stapelberg]

So, the xcb-proto patch is committed but it seems like it’ll take some time until there will be a new libxcb/xcb-proto release: http://lists.freedesktop.org/archives/xcb/2015-July/010459.html

[stapelberg]

Status update: the libxcb 1.12 release contains the necessary changes. I’ve filed http://bugs.debian.org/830491 to get it packaged in Debian.

I haven’t yet had a chance to test my changes to i3 on real hardware, but I hope I can do so some time in the coming weeks. I think using Xorg 1.18 and the intel driver should give me a test environment (commit https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=1be5b715827ef2bbc75ef795c301a1a7ba6e5f09 seems relevant).