Be more descriptive about user defined vs default monitors in randr and allow...
Be more descriptive about user defined vs default monitors in randr and allow more than one virtual monitor per physical output
Background
I have discussed in the mailing list if we could allow more than one monitor per output. I got the following response from @keithp , the original author of that part of the spec:
That's actually required in the RandR spec:
For each output in 'info.outputs, each one is removed from all pre-existing Monitors. If removing the output causes the list of outputs for that Monitor to become empty, then that Monitor will be deleted as if RRDeleteMonitor were called.
The notion of splitting one physical output into multiple virtual monitors was not considered when this extension was defined, which is why it doesn't work. I don't see any particular reason for not supporting your use case.
However, there are subtleties here. We want to remove any automatically created 'Monitor' objects when mapping user-specified monitors to them, and we want to re-generate automatically generated 'Monitors' when all virtual monitors associated with an output are removed.
I think what we want is:
- If no user-specified Monitors map to a particular Output, then automatically create a Monitor for that Output
- If any user-specified Monitors map to a particular Output, then remove the automatically generated Monitor for that Output.
In the current spec, there's no real separation between user-specified and automatically-generated Monitors, I think that would be necessary to make this work?
I have created a merge request that results in the desired behavior at xorg/xserver!981 (merged). This PR adds the required change to the spec as well. In addition, I have also added the behavior of the default vs. user defined monitors to the spec - this reflects the actual behavior of the xorg implementation.
@keithp I'd be happy if you find the time to look over the change and tell if you can approve this or if further changes or discussion are required.
Merge request reports
Activity
mentioned in merge request xorg/xserver!981 (merged)
requested review from @keithp
@keithp Would you merge it please?
@keithp Sorry to bother you again. Would you please merge this change or let me know what I need to do to get it merged? Thank you in advance, Michael.
added 7 commits
-
ef8d0bd0...fca42f2e - 6 commits from branch
xorg/proto:master - 7ae8c6d7 - Be more descriptive about user defined vs default monitors in randr and allow...
-
ef8d0bd0...fca42f2e - 6 commits from branch
added 9 commits
-
3464d917...e5cccecd - 8 commits from branch
xorg/proto:master - 53b41049 - Be more descriptive about monitor types
-
3464d917...e5cccecd - 8 commits from branch
Can't wait for this to be a real thing. I have a similar use case, but for something different than everyone else. 3 display split, where the primary display is in the middle, doing a normal 4:3 slice (e.g. 2880x2160) and the two leftovers on the left and right display important statistics, such as sensors/processes/etc. I've been wanting this for many many years, and glad to see progress on this front. Thank you to all for the efforts so far.
I fear there is no progress. I try to get this (plus the PR to xorg) merged since almost a year. I have emailed a bunch of xorg developers personally and pinged them through the tickets here. I also wrote to the devel mailing list several times.
It is deeply frustrating and I'm about to give up with this and switch back to windows on my next development machine.
Edited by Michael WyrazI think we just need more people aware of the benefits. I had the same sorts issues about 20 years ago, which caused me to abandon Kernel development. It's as if people don't understand the "why" you would want a feature, but yet once they discover you were right, they do what you wanted, possibly in a different way, can claim they came up with the entire idea. Politics like this sucks. All I can do personally is express my thanks to those who are like minded, and help spread good USEFUL ideas to others.
That all said, there's nothing preventing anyone from making a fork (their argument, which is valid). What the key here is showing a larger distro such an advantage of a modification, and having the maintainer agree. It seems only then do great ideas become "acceptable". Basically, you need to be more public about the patch, other than just trying to convince a few at the top. How to do that, I not only have no idea, but I'm quite a busy person, who lacks time.
HEY DEVS, we want this you are short sighted! comes off as an insult, even if you happen to be correct. I've had this battle many times, and well, all you can do is say "I warned you, and it sucks when I was correct."
Right, and thus, the squeaky wheel gets the grease/more people need to know about it/more demand. On top of that feature requests do tend to fall below feature request merges.
Since I don't do social media (because it's toxic AF) getting the word out is difficult. Basically there needs to be an event that gets noticed to make noise. It's a real shame when feature requests fall by the way-side, and if the devs aren't pushing it. They could be just busy fixing other important things, and don't want to throw in yet another feature that needs to be checked if it affects current bugs. Keep making noise, get more people involved, get it noticed.
