Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TODO: Rework disabled output handling (DisplayPort MST, hot-plug graphics) #8

Closed
tachylatus opened this issue Jan 6, 2015 · 7 comments

Comments

@tachylatus
Copy link
Contributor

Since the introduction of DisplayPort MST and hot-pluggable graphics cards, we can no longer assume the list of outputs is stable.
We need to implement a different logic for disabled outputs:

  • autorandr config should only contain enabled outputs
  • on config load, all other outputs should be disabled
@phillipberndt
Copy link
Owner

Sounds reasonable.

Since this is a major change, let's wait a few days with this: Regarding the licensing issue #7, I noticed that much of wertarbyte's code is too trivial to be rewritten in another way, and I don't know enough about copyright law to be absolutely certain that this is not a problem. I wrote him an email yesterday, and hopefully he'll reply. If he doesn't, this conceptual change would be a great opportunity to rewrite the whole thing from scratch, keeping configuration/parameter compatibility of course. (autorandr isn't that big/complicated, after all.. and we could switch to Python or Perl to ditch the awk/sed scripts.)

@tachylatus
Copy link
Contributor Author

Yeah, I guess it would make sense to just rewrite it, although I don't have much experience with neither Python nor Perl ;-)

I was planning on working on these new issues/requests myself (see #9).

@phillipberndt
Copy link
Owner

I couldn't resist: https://github.com/phillipberndt/autorandr/blob/license/autorandr.py

This is very early and experimental code, and I haven't tested it very much. Both your suggestions should already work though. Please consider this as a suggestion on where we could go with autorandr rather than something I'd like to impose on anyone.. I'm open to suggestions.

(I'll write a follow-up to #7 tomorrow, where I'll also ask the others that don't follow this issue for their opinion & more on why I think a rewrite is the safest option.)

@tachylatus
Copy link
Contributor Author

Haha, that's brilliant!
I couldn't resist either, and have been learning Perl since yesterday.

Here's my little Perl experiment:
https://github.com/tachylatus/autorandr/blob/perl-experiment/autorandr.pl

I only just got the xrandr output parsing working (including transform matrix and reflections), but the whole program is far from done.
Anyway, your Python version looks much nicer, so I guess I'll start learning some Python now :-)

@phillipberndt
Copy link
Owner

See #7; a bash implementation of this might be of interest, after all. (Depends on which version you'll be going to use. ;-))

@phillipberndt
Copy link
Owner

Does this work as expected for you in the Python version? It should, but I still haven't thoroughly tested this.

@phillipberndt
Copy link
Owner

I have been using this for some time now and it seems to be stable. This night need some changes to properly support providers when RandR 1.5 becomes more widespread, still, for now, I'll close this as fixed.

(See also: http://cgit.freedesktop.org/xorg/app/xrandr/commit/?id=d06730e94320175d40ff6f2bb38dce55312f2e54)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants