Translate

Arm Ukraine, zap Putin

Stolen Votes

berklix.com logo

berklix.org logo

No Cookies

Flag UK DE

BSD-PIE

BSD

GNU

Linux

No Tracking

Disclaimer

IBU

Consol

Notes on using Xrandr

by Julian H. Stacey

URL: http://www.berklix.com/~jhs/dots/.screenlayout/

(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

Stolen VotesBerklix.Net Computer AssociatesDomainsApache: Web ServerFreeBSD: Operating System