Slashdot Mirror


RandR Support on XFree86 4.3

Gentu writes "Great news from our favorite windowing system: [Hewlett-Packard] engineers committed a new extension to XFree86, called RandR. XFree86 4.3 (to be released in late 2002/early 2003), will have the ability to truly resize (not via the pseudo-resize CNTRL+[+/-] command), rotate, reflect and change the refresh rate of each screen of an X display on the fly. And KDE seems to be the first desktop environment to add support for the RandR extension."

2 of 503 comments (clear)

  1. An abstract by jaxdahl · · Score: 2, Redundant

    The X Window System protocol, Version 11, was deliberately designed to be extensible, to provide for both anticipated and unanticipated needs. The X11 core did not anticipate that the properties of X server screens might need to change dynamically, as occurs frequently with desktops, laptops and hand held computers not envisioned in the 1980's.

    The Resize and Rotate extension (RandR) is a very small set of client and server extensions designed to allow clients to modify the size, accelerated visuals and rotation of an X screen. RandR also has provisions for informing clients when screens have been resized or rotated and it allows clients to discover which visuals have hardware acceleration available.

    RandR needs to be discussed in concert with recent developments in X server implementation and the new Render extension to understand the implications of the aggregate. In isolation, RandR seems to provide a limited but useful improvement, but together with the Render extension and reimplementation of the X server rendering code, RandR provides part of a key change in X Window System capabilities.

  2. Re:The change I want to see... by Caktus · · Score: 1, Redundant

    Sun Ray terminals are similar in concept to VNC terminals (if they existed). There is a server to which the terminals connect using a propietary protocol. The X server runs on the server and the terminal is just a framebuffer with keyboard, mouse, USB sockets and audio. When you start a session you start an X server. When you switch terminals you disconnect from your X server and reconnect with another terminal. This method requires a dedicated *monster* server that has enough memory for each frame buffer, has enough cpu power to draw into the frame buffers and has dedicated networks with enough bandwith to the terminals.

    What would be really interesting is migrating aplications from one X server to the other transparently just using the X protocol. Without dedicating a server to the task, or having to migrate the entire session.