[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support.
From: |
Mathieu OTHACEHE |
Subject: |
Re: [RP] [PATCH 3/6] Disable sfdump if there is no xrandr support. |
Date: |
Mon, 28 Nov 2016 12:09:43 +0100 |
User-agent: |
mu4e 0.9.17; emacs 25.2.50.1 |
Hello,
Jeremie Courreges-Anglas writes:
> This makes me think that screens are currently sorted with only a
> "left < right" criteria, maybe total ordering with an additional
> "top < bottom" could be interesting.
Yes I agree, it could be interesting for people using vertical or vertical +
horizontal screen setup. I'll propose a patch soon.
>
> (Which makes me think that screen_sort() happens early, thus we
> should probably check that we do respect Xrandr's rotations even when
> they happen early / before ratpoison even exists...)
I'm not sure I understand you here.
If your issuing an xrandr command containing rotations then starting
ratpoison in your xinitrc for example, ratpoison is detecting
screens with rotations already applied.
> My lack of knowledge about multiple-screens setups strikes again: do you
> mean to say that just unplugging a screen makes Xrandr notify ratpoison
> that the screen went away? I thought that some kind of manual (or
> preconfigured) intervention with xrandr(1) or any other GUI tool was
> needed. If not, I'd say that
Well, we are able to detect two things:
* A screen is unplugged physically. Xrandr will tell us that the output
is gone (Disconnected) but that the crtc (the video buffer) is still
present. The output becomes "Virtual".
=> In that case we do nothing.
* The user uses xrandr(1) or any other tool to remove a screen (xrandr
--output XXX --off), the screen being physically plugged or unplugged.
We will be notified that the crtc is removed.
=> In that case we remove the screen in ratpoison list of screens.
That would be here that the numset would be released.
> Well, if screen A in unplugged from "slot 1" and screen B is then
> plugged in "slot 1", then I think this is the desired behavior. BTW, do
> the Xrandr IDs change when you do that?
It seems that xrandr is attributing an id to every possible screen
(DP-1, DP-2, HDMI-1, ...), at startup,
independently of its current state (connected/disconnected).
So if you plug a screen A on your HDMI port, then unplug it and plug
a screen B on the same HDMI port, the same id will be used for both
screens.
>
>> What's your opinion about it ?
>
> Sounds good at first, I think providing a stable ordering for static
> setups is enough to make current users happy. I'm wondering how much
> people are relying on sselect.
Ok, then I'll propose a new patch set soon.
> >> Thanks,
>
> Thank *you* in advance for bearing with me. I'm really a "one laptop
> screen will do" kind of guy. This Xrandr thingie almost makes me want
> to buy extra screens just so that I can stop looking stupid. :)
Mathieu
[RP] [PATCH 2/6] Use xrandr output identifiers in sselect., Mathieu OTHACEHE, 2016/11/25
[RP] [PATCH 5/6] Kill gcc uninitialized warning, Mathieu OTHACEHE, 2016/11/25
[RP] [PATCH 4/6] Use xrandr output identifiers in srestore., Mathieu OTHACEHE, 2016/11/25
[RP] [PATCH 6/6] Update XRandr related documentation and man., Mathieu OTHACEHE, 2016/11/25