Translate
IBU
Consol
|
|
Notes on using Xrandr
(either as direct CLI command or via GUI arandr)
JJLATER Merge in: ~jhs/tech/xrandr/
Cautions:
Ever since I've been using xrandr, periodically X crashes.
It did not use to with same load &
X.Org X Server 1.7.7
Release Date: 2010-05-04
FreeBSD 9.2-RELEASE amd64
Chipset: "ATI Radeon VE/7000 QY (AGP/PCI)" (ChipID = 0x5159)
(at 2014-04 there's probably newer drivers to try JJLATER)
There's a bug too, in driver, (not in arandr), scrambling
parts of the frame buffer in the DVI (but not VGA) output.
If xrandr commands scramble the display, that means, eg:
- the mouse displays on both VGA & DVI
- xterms & arandr & xeyes only display on DVI
old obsolete bitmap from a previous xdm login session remains on VGA
(Which could include private text from a previous session)
If you cannot recover with more xrandr commands, then don't reboot,
just rsh to display host & kill the X server.
ps -laxww | grep /usr/local/bin/X
/usr/local/bin/X :0 -auth /var/lib/xdm/authdir/authfiles/A:0-CkjzE8 (Xorg)
If a login was started from xdm in /etc/ttys,
If xrandr commands scrambles the display, the X server is Not
fixed by logging out & in again, (as the X server is Not restarted).
This thus leaves displays open to a local DOS (Denial Of Service) attack
eg in a public terminal room, where if short of terminals,
rogues could scramble a screen to leave it unoccupied, to be
rescued on return by typing correct xrandr commands blind to fix
it, (if they knew where to mouse focus to an xterm), (they could
alternately use xlock, bt that would obviously attract attention).
It would be better if xdm or xsm sent some xrandr commands at
each logout/login, or better restart X.
echo "A child of xdm: `cat /var/run/xdm.pid`"
man xdm:
DisplayManager.DISPLAY.resetSignal
The number of the signal xdm sends to reset the
server. See the section Controlling the Server.
The default is 1 (SIGHUP).
ps -laxww | grep /usr/local/bin/X
/usr/local/bin/X :0 -auth /var/lib/xdm/authdir/authfiles/A:0-CkjzE8 (Xorg)
Rotated (Vertical) output devices:
Best place in them windows of static immobile nature, eg xterms with
long screeds of reference code eg C or .procmail rules etc,
Avoid placing any window there that has fast changing images, as
The X server slows the hosts while it slowly remaps images.
Things to avoid are:
Browsers if with flickering adverts especially if java berserk
All video players inc. such as mplayer, xine etc
gkrellm with flickering status
xmms with pulsing audio frequency display
xterm if fast scrolling eg a make running.
Overlays
Probably best to minimise or avoid overlay of multiple outputs from
common areas within the frame buffer. It works, but presumably wastes
performance.
/usr/ports/x11/arandr
http://svnweb.freebsd.org/ports/head/x11/arandr/pkg-descr?view=markup
Generic http://christian.amsuess.com/tools/arandr/
Nice graphical tool, misses fancy bits like '--primary' but saves
to shells you can edit yourself later. Uses '--pos' & avoids using eg
'--left-of' (which helps avoid ticking X bugs).
Wide multi screens - Not if you don't have a big frame buffer !
Most laptops seem to just have a frame buffer of 1024 x 768 to match
their screen of 1024 x 768, so you'll be out of luck if you want
to do split panel screening with a big external screen.
One tower I have, with a dedicated graphics card has a relatively
big frame buffer of:
xrandr | grep Screen
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 1680 x 1680
Another host with VGA off the main board also has just 1024 x 1024
I guess one usually needs to use plug in cards for bigger frame buffers.
/var/log/Xorg.0.log shows card insufficient to drive DVI in preferred mode
(II) RADEON(0): First detailed timing is preferred mode
(II) RADEON(0): #0: hsize: 1920 vsize 1080 refresh: 60 vid: 49361
(II) RADEON(0): Not using mode "1920x1080" (width too large for virtual size)
X server or xrandr or driver bug (not sure where bug lies):
Sometime when doing an xrandr command, it forgets that my VGA
output is supposed to be vertical. If I have previously specified
my DVI as --right-of VGA, then 2 horizontals exceeds frame buffer
width, & X can fail & has to be killed (arandr avoids that, it warns too big
instead of trying).
Sometimes xrandr ignores --rotate left , perhaps because some state
table thinks it already is, this can be fooled by successive commands with
--rotate right then --rotate left
FVWM should be restarted after xrandr has changed layout.
Fvwm understands outputs for panel manager, & eg when doing
Maximise on an xterm.
Brightness
xrandr --output VGA-0 --brightness 0.9
xrandr --output DVI-0 --brightness 0.9
xrandr --output LVDS-0 --brightness 0.9 # Fails on laptop
|
