A few days ago I decided to have a deeper look at the API of the Python bindings for Xrandr (pyxrandr) written by Sebastian Heinlein and Michael Vogt. While I must admit that they did a good work with the bindings I’m still not completely satisfied with what I can do with them. This is not a complaint, actually I’m quite happy since it will give me a reason to learn C and complete the bindings myself (when I have the time). In the meantime I will use such bindings in URandR in at least 2 ways:
1) To achieve compatibility with drivers which support only RandR 1.1 (such as “nvidia”, “fglrx”, etc.)
2) To drop hardcoded names of the outputs for the sake of a more dynamic detection
As regards point 1, this screenshot shows how URandR works with NVIDIA’s proprietary driver as well:
If a driver doesn’t support RandR 1.2 you will only be able to change its resolution, refresh rate and to rotate the screen. This means that I won’t have to check which driver you’re using by reading your “/proc/$(pidof X)/maps”, which requires having root permissions. If URandR can get the current rotation of the screen through the xrandr bindings then the driver supports RandR 1.2, otherwise URandR will use compatibility mode.
Thanks to point 2 I won’t have to worry about the names by which each driver refers to output connections. For example this table contains the names of the outputs used by the ATI (radeon) driver and by the Intel driver:
Ati
(radeon) |
Intel |
| VGA-0 |
VGA |
| LVDS |
LVDS |
| DVI-0 |
TMDS-1 |
| S-video |
TV |
I assume that drivers such as radeonhd, nouveau, etc. which support RandR 1.2 use other names. Fortunately I’ll no longer have to deal with their idiosyncrasies (directly) since the xrandr python bindings give URandR access to such names at runtime. Another thing I won’t have to worry about is the number of monitors, tvs, etc. that you connect to your graphic card. If you can connect 20 screens at the same time (provided that such thing is possible and that the driver supports it) URandR will detect them all. Thanks to these changes I was able to improve my own detection library (which is *a bit* more readable) and to make it much more dynamic as well.
Here are my plans for the next release of URandR:
* Support for RandR 1.x (DONE)
* Support for any driver which supports RandR 1.2 (DONE)
* PolicyKit integration – so that you don’t have to
be root in order to run URandR and that if the
framebuffer is not enough URandR can ask your
root password only to set the virtual resolution
in your xorg.conf
* When you apply your settings, things can go wrong,
therefore URandR will show a dialog with a countdown
and a button which, if not clicked in time (if for example
you disabled your main screen by mistake), will revert to
your previous settings.
When the new URandR is ready I will work on an alternative interface in QT4.
Here are a two screenshots of URandR with the Intel driver with my laptop screen (LVDS) (virtually) positioned to the left of an external monitor (VGA):
As you can see, each output has its own place in the treeview instead of having its own tab.
When will all this be available? I don’t know, however I’m going to graduate (yes, again…) next week therefore I guess I’ll have (relatively, as usual…) plenty of time to work on URandR.
