The X Window System. The Athena project at MIT was a joint effort between
that university and Digital Equipment to create a graphical interface for Unix,
which was finally released in April of 1994.
The current version of X, which is now the standard graphical interface for Unix,
is Version 11, Release 6. X Windows, often called ``X'', is also known as X11R6
(pronounced ``ex eleven, are 6''). X Windows is the generic name for that overall
program that interfaces the graphical software environment with your system's hardware.
The X Window system consists of three main parts - the X server, the window manager
and the clients.
The X Server. The ubiquitous XFree86 is a free version that is quite
good in its own right. It is distributed under the GNU public license. Most
all Linux distributions come with XFree86.
The Window Manager. The window manager governs the actual look and
feel of your X Windows graphical environment. The hardware and system needs
of the graphical environment are handled by the X Server, but the actual appearance
and behavior are handled by the humble window manager.
There are many different window managers which are all designed to run on
X11R6. This is because X11R6 is standard and uniform, hopefully, so window managers
can be also. One of the most popular on Linux are Gnome and KDE.
X Clients. The graphical environment is useless unless you have software
that runs on it. Those individual software programs that run on X Windows are
called X Clients. The thing to remember about an X client is that it usually
only runs under X Windows. Many programs run under a non-graphical interface
as well as X Windows itself, but these use programs use two different resources.
X clients normally use one of the many graphical toolkits available for X
Windows. These are libraries of common pieces of code that different programs
may share on an X Windows system. Several such ``toolkits'' exist that are popular
among developers, so your X client programs may actually look different in some
respects. One program may use "widgets'' (radio buttons, checkboxes, scrollbars,
etc) from the Motif libraries, while another program may use Tk libraries, while
still another may use X Forms libraries. This is permissible under X Windows,
and some client software may even be available for compiling under your choice
of graphical libraries.
One of the most interesting feature of X Window System is the ability to export
display to other computer over TCP/IP network. See
Exporting_display for details.
In addition to the X server itself, here are a few of the noteworthy utilities:
xdm - the X Display Manager.
xfs - the X Font Server.
twm - a lightweight Window Manager.
xterm - the best known terminal emulator.
xwd - a screen and window image capturer.
xf86config - X server configuration utility.
xdpyinfo - X display information utility. This shows
great detail about the X server.
xlsclients - lists currently connected X server clients.
xlsfonts - lists fonts available to
X.
appres - lists the X "resources"
that a program will use.
xfontsel - an application for viewing or selecting
fonts.
xprop - a tool for displaying window
"properties", such as the Class name of the client.
xset - sets user preferences for many things, including
mouse, keyboard, sound (bell), etc.
xsetroot - a program for changing the
"root window" appearance, e.g. setting a background
color.
xvidtune - an application to adjust X server video
modes and monitor related settings.
xwininfo - displays information about a selected
"window".
xmodmap - a utility for manipulating keyboard and
mouse button mappings.
We'll be installing TigerVNC. It is an actively maintained high-performance VNC server. Type the following command to install the
package:
sudo apt install tigervnc-standalone-serverCopy
Configuring VNC Access
Once the VNC server is installed, the next step is to create the initial user configuration and set up the password.
Set the user password using the
vncpasswd
command.
Do not use sudo when running the command below:
vncpasswdCopy
You will be prompted to enter and confirm the password and whether to set it as a view-only password. If you choose to set up a
view-only password, the user will not be able to interact with the VNC instance with the mouse and the keyboard.
Password:
Verify:
Would you like to enter a view-only password (y/n)? n
Copy
The password file is stored in the
~/.vnc
directory,
which is created if not present.
Next, we need to configure TigerVNC to use Xfce. To do so, create the following file:
New 'server2.linuxize.com:1 (linuxize)' desktop at :1 on machine server2.linuxize.com
Starting applications specified in /home/linuxize/.vnc/xstartup
Log file is /home/linuxize/.vnc/server2.linuxize.com:1.log
Use xtigervncviewer -SecurityTypes VncAuth -passwd /home/linuxize/.vnc/passwd :1 to connect to the VNC server.
Copy
Note the
:1
after
the
hostname
in
the output above. This indicates the number of the display port on which the vnc server is running. In this example, the server
is running on TCP port
5901
(5900+1).
If you create a second instance with
vncserver
it
will run on the next free port i.e
:2
,
which means that the server is running on port
5902
(5900+2).
What is important to remember is that when working with VNC servers,
:X
is
a display port that refers to
5900+X
.
You can get a list of all the currently running VNC sessions by typing:
vncserver -listCopy
TigerVNC server sessions:
X DISPLAY # RFB PORT # PROCESS ID
:1 5901 5710
Copy
Before continuing with the next step, stop the VNC instance using the
vncserver
command
with a
-kill
option
and the server number as an argument. In this example, the server is running in port 5901 (
:1
),
so we'll stop it with:
The number
1
after
the
@
sign
defines the display port on which the VNC service will run. This means that the VNC server will listen on port
5901
,
as we discussed in the previous section.
● [email protected] - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/[email protected]; enabled; vendor preset: enabled)
Active: active (running) since Fri 2021-03-26 20:00:59 UTC; 3s ago
...
Copy
Connecting to VNC server
VNC is not an encrypted protocol and can be subject to packet sniffing. The recommended approach is to create an
SSH
tunnel
and securely forward traffic from your local machine on port 5901 to the server on the same port.
Set Up SSH Tunneling on Linux and macOS
If you run Linux, macOS, or any other Unix-based operating system on your machine, you can easily create an SSH tunnel with the
following command:
Make sure to replace
username
and
server_ip_address
with
your username and the IP address of your server.
Set Up SSH Tunneling on Windows
If you run Windows, you can set up SSH Tunneling using the
PuTTY
SSH client
.
Open Putty and enter your server IP Address in the
Host
name or IP address
field.
Under the
Connection
menu,
box, expand
SSH
,
and select
Tunnels
.
Enter the VNC server port (
5901
)
in the
Source
Port
field and enter
server_ip_address:5901
in
the
Destination
field
and click on the
Add
button
as shown in the image below:
Go back to the
Session
page
to save the settings, so you do not need to enter them each time. To the remote server, select the saved session and click on
the
Open
button.
Connecting using Vncviewer
Now that the SSH tunnel is created, it is time to open your Vncviewer and to connect to the VNC Server at
localhost:5901
.
You can use any VNC viewer such as TigerVNC, TightVNC, RealVNC, UltraVNC, Vinagre, and VNC Viewer for
Google
Chrome
.
We'll be using TigerVNC. Open the viewer, enter
localhost:5901
,
and click on the
Connect
button.
Enter
your
user
password when prompted, and you should see the default Xfce desktop. It will look something like this:
You can start interacting with the remote XFCE desktop from your local machine using your keyboard and mouse.
Conclusion
We've shown you how to install and configure a VNC server up and running, on Ubuntu 20.04.
To configure your VNC server to start a display for more than one user, create the initial configuration and set up the password
using the
vncpasswd
command.
You will also need to create a new service file using a different port.
Feel free to leave a comment if you have any questions.
If you have performed a RHEL 7 Linux Server installation and did not include Graphical User
Interface (GUI) you can do it later directly from command line using yum command
and selecting an appropriate installation group. To list all available installation groups on
Redhat 7 Linux use:
[root@rhel7 ~]# yum group list
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
There is no installed groups file.
Maybe run: yum groups mark convert (see man yum)
Available environment groups:
Minimal Install
Infrastructure Server
File and Print Server
Basic Web Server
Virtualization Host
Server with GUI
Available Groups:
Compatibility Libraries
Console Internet Tools
Development Tools
Graphical Administration Tools
Legacy UNIX Compatibility
Scientific Support
Security Tools
Smart Card Support
System Administration Tools
System Management
Done
Looking for Linux Systems Analyst !
The UAF Geophysical Institute, is looking for an experienced Linux Systems Analyst to
join their team of research cyber infrastructure analysts and engineers. LOCATION:
Fairbanks, Alaska, USA
From the above list select Server with GUI installation group:
[root@rhel7 ~]# yum groupinstall 'Server with GUI'
Transaction Summary
=================
Install 261 Packages (+604 Dependent packages)
Total download size: 527 M
Installed size: 1.7 G
Is this ok [y/d/N]:
Just because gnome desktop environment is a default GUI on RHEL 7 linux system the above
command will install gnome. Alternatively, you can run the below command to only install core GNOME
packages:
Once the installation is finished, you need to change system's runlevel to runlevel 5.
Changing runlevel on RHEL 7 is done by use of systemctl command. The below command
will change runlevel from runlevel 3 to runelevel 5 on RHEL 7:
Depending on your previous installations you may need to accept Redhat License after you
reboot your system. Once you boot to your system you can check GNOME version using:
Download the Nvidia driver package from nvidia.com using search criteria based on
your Nvidia card model and the Linux operating system. Download an appropriate
Nvidia driver for your VGA card. Alternatively, if you know what you are doing you can
download the driver directly from the Nvidia Linux driver list . Once ready you
should end up with a file similar to the one shown below:
$ ls NVIDIA-Linux-x86_64-*
NVIDIA-Linux-x86_64-460.39.run
Next, install package
prerequisites to be able successfully compile and install Nvidia driver on you AlmaLinux
system.
WARNING
Depending on your Nvidia VGA model your system might misbehave. At this stage be ready to
get your hands dirty. After the reboot you may end up without GUI at all. Be sure that
you have the SSH enabled on your system to
be able login remotely or use CTRL+ALT+F2 to switch TTY console and continue
with the installation.
# reboot
The Nvidia drivers must be installed while the Xorg server is stopped. Switch to the text
mode by:
# systemctl isolate multi-user.target
Install the Nvidia driver by executing the following command via TTY console or remote
SSH login:
When prompted answer
YES to installation of NVIDIA's 32-bit compatibility libraries. Allow automatically
update of your X configuration file.
You should see the following message after successful NVIDIA driver installation.
Reboot your system one more time.
All done. Reboot your system. The Nvidia driver should now be installed on your AlamLinux 8
Desktop. Login and run nvidia-settings to further configure your Nvidia
graphic card settings.
# reboot
Troubleshooting GDM on Xorg server does not start after user login and user ends up with
black screen. The Xorg log contains the following or similar error messages:
[ 3515.464] (II) systemd-logind: got pause for 13:68
[ 3515.738] (II) systemd-logind: got resume for 13:64
[ 3515.757] (II) NVIDIA(0): Setting mode "DFP-1:nvidia-auto-select"
[ 3515.793] (II) NVIDIA(0): ACPI: failed to connect to the ACPI event daemon; the daemon
[ 3515.793] (II) NVIDIA(0): may not be running or the "AcpidSocketPath" X
[ 3515.793] (II) NVIDIA(0): configuration option may not be set correctly. When the
[ 3515.793] (II) NVIDIA(0): ACPI event daemon is available, the NVIDIA X driver will
[ 3515.793] (II) NVIDIA(0): try to use it to receive ACPI event notifications. For
[ 3515.793] (II) NVIDIA(0): details, please see the "ConnectToAcpid" and
[ 3515.793] (II) NVIDIA(0): "AcpidSocketPath" X configuration options in Appendix B: X
[ 3515.793] (II) NVIDIA(0): Config Options in the README.
[ 3515.793] [dix] couldn't enable device 8
[ 3515.793] (II) systemd-logind: got resume for 13:66
[ 3515.793] [dix] couldn't enable device 6
[ 3515.794] (II) systemd-logind: got resume for 13:65
[ 3515.794] [dix] couldn't enable device 7
[ 3515.794] (II) systemd-logind: got resume for 13:72
[ 3515.794] [dix] couldn't enable device 14
[ 3515.794] [dix] couldn't enable device 17
[ 3515.794] (II) systemd-logind: got resume for 13:71
[ 3515.794] [dix] couldn't enable device 13
[ 3515.794] (II) systemd-logind: got resume for 13:67
[ 3515.794] [dix] couldn't enable device 9
[ 3515.794] (II) systemd-logind: got resume for 13:73
[ 3515.794] [dix] couldn't enable device 15
[ 3515.794] (II) systemd-logind: got resume for 13:69
[ 3515.794] [dix] couldn't enable device 11
[ 3515.794] [dix] couldn't enable device 16
[ 3515.794] (II) systemd-logind: got resume for 13:70
[ 3515.794] [dix] couldn't enable device 12
[ 3515.794] (II) systemd-logind: got resume for 13:68
[ 3515.794] [dix] couldn't enable device 10
Accessing remote desktops Need to see what's happening on someone else's screen? Here's what you need to know about accessing
remote desktops.
Posted June 13, 2019 | by Seth Kenlon (Red Hat)
Anyone who's worked a support desk has had the experience: sometimes, no matter how descriptive your instructions,
and no matter how concise your commands, it's just easier and quicker for everyone involved to share screens. Likewise, anyone who's
ever maintained a server located in a loud and chilly data center -- or across town, or the world -- knows that often a remote viewer
is the easiest method for viewing distant screens.
Linux is famously capable of being managed without seeing a GUI, but that doesn't mean you have to manage your box that
way. If you need to see the desktop of a computer that you're not physically in front of, there are plenty of tools for the job.
Barriers
Half the battle of successfully screen sharing is getting into the target computer. That's by design, of course. It should
be difficult to get into a computer without explicit consent.
Usually, there are up to 3 blockades for accessing a remote machine:
The network firewall
The target computer's firewall
Screen share settings
Specific instruction on how to get past each barrier is impossible. Every network and every computer is configured uniquely, but
here are some possible solutions.
Barrier 1: The network firewall
A network firewall is the target computer's LAN entry point, often a part of the router (whether an appliance from an Internet
Service Provider or a dedicated server in a rack). In order to pass through the firewall and access a computer remotely, your network
firewall must be configured so that the appropriate port for the remote desktop protocol you're using is accessible.
The most common, and most universal, protocol for screen sharing is VNC.
If the network firewall is on a Linux server you can access, you can broadly allow VNC traffic to pass through using firewall-cmd
, first by getting your active zone, and then by allowing VNC traffic in that zone:
If you're not comfortable allowing all VNC traffic into the network, add a rich rule to firewalld in order to let
in VNC traffic from only your IP address. For example, using an example IP address of 93.184.216.34, a rule to allow VNC traffic
is:
To ensure the firewall changes were made, reload the rules:
$ sudo firewall-cmd --reload
If network reconfiguration isn't possible, see the section "Screen sharing through a browser."
Barrier 2: The computer's firewall
Most personal computers have built-in firewalls. Users who are mindful of security may actively manage their firewall. Others,
though, blissfully trust their default settings. This means that when you're trying to access their computer for screen sharing,
their firewall may block incoming remote connection requests without the user even realizing it. Your request to view their screen
may successfully pass through the network firewall only to be silently dropped by the target computer's firewall.
Changing zones in Linux.
To remedy this problem, have the user either lower their firewall or, on Fedora and RHEL, place their computer into the trusted
zone. Do this only for the duration of the screen sharing session. Alternatively, have them add either one of the rules you added
to the network firewall (if your user is on Linux).
A reboot is a simple way to ensure the new firewall setting is instantiated, so that's probably the easiest next step for your
user. Power users can instead reload the firewall rules manually :
$ sudo firewall-cmd --reload
If you have a user override their computer's default firewall, remember to close the session by instructing them to re-enable
the default firewall zone. Don't leave the door open behind you!
Barrier 3: The computer's screen share settings
To share another computer's screen, the target computer must be running remote desktop software (technically, a remote desktop
server , since this software listens to incoming requests). Otherwise, you have nothing to connect to.
Some desktops, like GNOME, provide screen sharing options, which means you don't have to launch a separate screen sharing application.
To activate screen sharing in GNOME, open Settings and select Sharing from the left column. In the Sharing panel, click on Screen
Sharing and toggle it on:
Remote desktop viewers
There are a number of remote desktop viewers out there. Here are some of the best options.
GNOME Remote Desktop Viewer
The GNOME Remote Desktop Viewer application is codenamed Vinagre
. It's a simple application that supports multiple protocols, including VNC, Spice, RDP, and SSH. Vinagre's interface is intuitive,
and yet this application offers many options, including whether you want to control the target computer or only view it.
If Vinagre's not already installed, use your distribution's package manager to add it. On
Red Hat Enterprise Linux and
Fedora , use:
$ sudo dnf install vinagre
In order to open Vinagre, go to the GNOME desktop's Activities menu and launch Remote Desktop Viewer . Once it opens, click the
Connect button in the top left corner. In the Connect window that appears, select the VNC protocol. In the Host field, enter the
IP address of the computer you're connecting to. If you want to use the computer's hostname instead, you must have a valid DNS service
in place, or Avahi , or entries in /etc/hosts . Do not prepend
your entry with a username.
Select any additional options you prefer, and then click Connect .
If you use the GNOME Remote Desktop Viewer as a full-screen application, move your mouse to the screen's top center to reveal
additional controls. Most importantly, the exit fullscreen button.
If you're connecting to a Linux virtual machine, you can use the Spice protocol instead. Spice is robust, lightweight, and transmits
both audio and video, usually with no noticeable lag.
TigerVNC and TightVNC
Sometimes you're not on a Linux machine, so the GNOME Remote Desktop Viewer isn't available. As usual, open source has an answer.
In fact, open source has several answers, but two popular ones are TigerVNC and
TightVNC , which are both cross-platform VNC viewers. TigerVNC
offers separate downloads for each platform, while TightVNC has a universal Java client.
Both of these clients are simple, with additional options included in case you need them. The defaults are generally acceptable.
In order for these particular clients to connect, turn off the encryption setting for GNOME's embedded VNC server (codenamed Vino)
as follows:
$ gsettings set org.gnome.Vino require-encryption false
This modification must be done on the target computer before you attempt to connect, either in person or over SSH.
Red Hat Enterprise Linux 7 remoted to RHEL 8 with TightVNC
Use the option for an SSH tunnel to ensure that your VNC connection is fully encrypted.
Screen sharing through a browser
If network re-configuration is out of the question, sharing over an online meeting or collaboration platform is yet another option.
The best open source platform for this is Nextcloud , which offers screen sharing
over plain old HTTPS. With no firewall exceptions and no additional encryption required,
Nextcloud's Talk app provides video and audio chat, plus whole-screen sharing
using WebRTC technology.
This option requires a Nextcloud installation, but given that it's the best open source groupware package out there, it's probably
worth looking at if you're not already running an instance. You can install Nextcloud yourself, or you can purchase hosting from
Nextcloud.
To install the Talk app, go to Nextcloud's app store. Choose the Social & Communication category and then select the Talk plugin.
Next, add a user for the target computer's owner. Have them log into Nextcloud, and then click on the Talk app in the top left
of the browser window.
When you start a new chat with your user, they'll be prompted by their browser to allow notifications from Nextcloud. Whether
they accept or decline, Nextcloud's interface alerts them of the incoming call in the notification area at the top right corner.
Once you're in the call with your remote user, have them click on the Share screen button at the bottom of their chat window.
Remote screens
Screen sharing can be an easy method of support as long as you plan ahead so your network and clients support it from trusted
sources. Integrate VNC into your support plan early, and use screen sharing to help your users get better at what they do. Topics:
Linux Seth Kenlon Seth Kenlon is a free culture
advocate and UNIX geek.
OUR BEST CONTENT, DELIVERED TO YOUR INBOX
https://www.redhat.com/sysadmin/eloqua-embedded-subscribe.html?offer_id=701f20000012gE7AAI The opinions expressed on this website
are those of each author, not of the author's employer or of Red Hat.
Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.
A certain piece of very misleading advice is often given online to users having problems
with the way certain command-line applications are displaying in their terminals. This is to suggest
that the user change the value of their TERM environment variable from within the shell,
doing something like this:
$ TERM=xterm-256color
This misinformation sometimes extends to suggesting that users put the forced TERM
change into their shell startup scripts. The reason this is such a bad idea is that it forces your
shell to assume what your terminal is, and thereby disregards the initial terminal identity string
sent by the emulator. This leads to a lot of confusion when one day you need to connect with a very
different terminal emulator.
Accounting for differences
All terminal emulators are not created equal. Certainly, not all of them are
xterm(1) , although many
other terminal emulators do a decent but not comprehensive job of copying it. The value of the
TERM environment variable is used by the system running the shell to determine what
the terminal connecting to it can and cannot do, what control codes to send to the program to use
those features, and how the shell should understand the input of certain key codes, such as the Home
and End keys. These things in particular are common causes of frustration for new users who turn
out to be using a forced TERM string.
Instead, focus on these two guidelines for setting TERM :
Avoid setting TERM from within the shell, especially in your startup
scripts like .bashrc or .bash_profile . If that ever seems like the
answer, then you are probably asking the wrong question! The terminal identification string should
always be sent by the terminal emulator you are using; if you do need to change it, then
change it in the settings for the emulator.
Always use an appropriate TERM string that accurately describes what your choice
of terminal emulator can and cannot display. Don't make an
rxvt(1) terminal identify
itself as xterm ; don't make a linux console identify itself as
vt100 ; and don't make an xterm(1) compiled without 256 color support
refer to itself as xterm-256color .
In particular, note that sometimes for compatibility reasons, the default terminal identification
used by an emulator is given as something generic like xterm , when in fact a more accurate
or comprehensive terminal identity file is more than likely available for your particular choice
of terminal emulator with a little searching.
An example that surprises a lot of people is the availability of the putty terminal
identity file, when the application defaults to presenting itself as an imperfect xterm(1)
emulator.
Configuring your emulator's string
Before you change your terminal string in its settings, check whether the default it uses is already
the correct one, with one of these:
$ echo $TERM
$ tset -q
Most builds of rxvt(1) , for example, should already use the correct TERM
string by default, such as rxvt-unicode-256color for builds with 256 colors and Unicode
support.
Where to configure which TERM string your terminal uses will vary depending on the
application. For xterm(1) , your .Xresources file should contain a definition
like the below:
XTerm*termName: xterm-256color
For rxvt(1) , the syntax is similar:
URxvt*termName: rxvt-unicode-256color
Other GTK and Qt emulators sometimes include the setting somewhere in their preferences. Look
for mentions of xterm , a common fallback default.
For Windows PuTTY, it's configurable under the "'Connections > Data"' section:
More detail about configuring PuTTY for connecting to modern systems can be found in my
article on configuring
PuTTY .
Testing your TERM string
On GNU/Linux systems, an easy way to test the terminal capabilities (particularly effects like
colors and reverse video) is using the
msgcat(1) utility:
$ msgcat --color=test
This will output a large number of tests of various features to the terminal, so that you can
check their appearance is what you expect.
Finding appropriate terminfo(5) definitions
On GNU/Linux systems, the capabilities and behavior of various terminal types is described using
terminfo(5) files,
usually installed as part of the ncurses package. These files are often installed in
/lib/terminfo or /usr/share/terminfo , in subdirectories by first letter.
In order to use a particular TERM string, an appropriate file must exist in one of
these directories. On Debian-derived systems, a large collection of terminal types can be installed
to the system with the
ncurses-term
package.
For example, the following variants of the rxvt terminal emulator are all available:
$ cd /usr/share/terminfo/r
$ ls rxvt*
rxvt-16color rxvt-256color rxvt-88color rxvt-color rxvt-cygwin
rxvt-cygwin-native rxvt+pcfkeys rxvt-unicode-256color rxvt-xpm
Private and custom terminfo(5) files
If you connect to a system that doesn't have a terminfo(5) definition to match the
TERM definition for your particular terminal, you might get a message similar to this
on login:
setterm: rxvt-unicode-256color: unknown terminal type
tput: unknown terminal "rxvt-unicode-256color"
$
If you're not able to install the appropriate terminal definition system-wide, one technique is
to use a private .terminfo directory in your home directory containing the definitions
you need:
You can copy this to your home directory on the servers you manage with a tool like scp
:
$ scp -r .terminfo server:
TERM and multiplexers
Terminal multiplexers like screen(1)
and tmux(1)
are special cases, and they cause perhaps the most confusion to people when inaccurate TERM
strings are used. The tmux
FAQ even opens by saying that most of the display problems reported by people are due to incorrect
TERM settings, and a good portion of the codebase in both multiplexers is dedicated
to negotiating the differences between terminal capacities.
This is because they are "terminals within terminals", and provide their own functionality only
within the bounds of what the outer terminal can do. In addition to this, they have their
own type for terminals within them; both of them use screen and its variants, such as
screen-256color .
It's therefore very important to check that both the outer and inner definitions
for TERM are correct. In .screenrc it usually suffices to use a line like
the following:
term screen
Or in .tmux.conf :
set-option -g default-terminal screen
If the outer terminals you use consistently have 256 color capabilities, you may choose to use
the screen-256color variant instead.
If you follow all of these guidelines, your terminal experience will be much smoother, as your
terminal and your system will understand each other that much better. You may find that this fixes
a lot of struggles with interactive tools like
vim(1) , for one thing,
because if the application is able to divine things like the available color space directly from
terminal information files, it saves you from having to include nasty hacks on the t_Co
variable in your .vimrc . Posted in
Terminal Tagged
term strings ,
terminal types
, terminfo
Ion is a tiling tabbed window manager designed with keyboard users in mind.
So-called "modern desktop environments" converge on total unusability, and present-day
mainstream graphical user interfaces in general are far less usable than they
are praised to be.
Usability simply does not equal low learning curve, and hiding system
details from the user, as the Official Truth seems to be these days. Convenience
foods are also easy and fast, but not very palatable (and you don't want to
know all the ingredients).
Those of us who prefer to use the computer primarily with the keyboard for
reasons of efficiency or health, are forgotten when "modern" graphical programs
are designed. Mouse-based search-and-click interfaces simply are not efficient
except for some very specialised tasks and in other cases involve lots of tedious
repetitive clicking and searching. While most widget-based GUIs provide keyboard
shortcuts to some operations, these are often sub-optimal – for example, commands
can often be superior to cryptic shortcuts – and the general
application design still makes them difficult to use from the keyboard.
For example, tabbing through dialog entries is difficult if the dialog is laid
out in a complex fashion. Most command line and other text mode programs are
simply much more usable once you get used to them, but are limited in their
output capabilities.
Summary of Ion features
Tiled workspaces with tabbed frames, as discussed above.
Designed to be primarily used from the keyboard.
Fully documented
configuration and scripting
interface on top of the lightweight Lua
extension language.
Modular design. The main binary implements only basic window manager
functionality. Additional modules implement extra features and window management
policies.
The query module implements a line editor similar to mini buffers in
many text editors. It is used to implement many different queries with tab-completion
support: show manual page, run program, open SSH session, view file, goto
named client window or workspace, etc. Menus are also displayed as queries.
A statusbar that adapts to the tilings, taking only the space it really
needs, modulo constraints of the layout. The statusbar can also be configured
to swallow other (small) windows, and does so automatically for
Window Maker protocol
dockapps, and KDE-protocol
system
tray icons.
Full screen client windows are seen as workspaces on their own. It is
possible to switch to a normal workspace while keeping several client windows
in full screen state and also switch clients that do not themselves support
full screen mode to this state.
The scratchpad module provides a conveniently toggleable area for random
tasks, akin to the consoles of many FPS games.
To run those particularly badly behaving programs, Ion also supports
floating windows of the
PWM flavour. These can be had as separate workspaces without an underlying
tiling, or floating on top of a tiling. Tiled windows can be detached to
float, and reattached.
It is not a project of the self-proclaimed
"free" or open-source software movement, and does not suffer from popular
fads among it, such as a
totalitarian approach to
font
blurring and autoconf.
Ion3 2 October 2008
Features include:
Tiled workspaces with tabbed frames
Designed to be primarily used from the keyboard
Fully documented configuration and scripting interface on top
of the lightweight Lua extension language
Modular design
The query module implements a line editor similar to mini buffers
in many text editors. It is used to implement many different queries
with tab-completion support: show manual page, run program, open
SSH session, view file, goto named client window or workspace, etc.
Menus are also displayed as queries
A statusbar that adapts to the tilings, taking only the space
it really needs, modulo constraints of the layout. The statusbar
can also be configured to swallow other (small) windows, and does
so automatically for Window Maker protocol dockapps, and KDE-protocol
system tray icons
Full screen client windows are seen as workspaces on their own.
It is possible to switch to a normal workspace while keeping several
client windows in full screen state and also switch clients that
do not themselves support full screen mode to this state
The scratchpad module provides a conveniently toggleable area
for random tasks, akin to the consoles of many FPS games
Supports floating windows of the PWM flavour. These can be had
as separate workspaces without an underlying tiling, or floating
on top of a tiling. Tiled windows can be detached to float, and
reattached
JWM
JWM (Joe's Window Manager) is a window manager for the X Window System written
by Joe Wingbermuehle. JWM is written in C and uses only Xlib at a minimum. Support
for the following can be added as compile-time options:
JWM is the default window manager used in Damn Small
Linux, System Rescue CD, most versions of Puppy Linux, and the
ultra-lightweight distribution
Slitaz.
Sawfish
Sawfish
is a window manager for the X Window System. Formerly known as Sawmill, the
name was changed because another software program had the same name (a commercial
web log analysis program). Distinctively, Sawfish
uses a Lisp-like scripting language, rep, for all of its code, making it particularly
easy to extend. For example, it can incorporate keybindings for
XMMS.
Sawfish does not come with a panel and was used with the GNOME desktop environment
until it was replaced by Metacity in GNOME 2.2.
Scwm
Scwm or Scheme Constraints Window Manager is a window manager for the X
Window System. Its main features are dynamic configurability and programmability
via a language based on GNU Guile and the embedded arithmetic Cassowary constraint
solver. Other features include flexible GUI-driven customization and per window
decoration settings (per window 'themes'). The primary developers were Greg
Badros and Maciej Stachowiak.
dwm
dwm is a minimalist dynamic tiling window manager for X11. It is externally
similar to wmii, but internally much simpler. dwm is written purely in C and,
for simplicity, lacks any configuration interface besides editing the source
code. This is not as inconvenient as it sounds, however: one of the project's
guidelines is that the source code will never exceed 2000 lines, and options
meant to be user-configurable are all represented by macros and contained in
a single header file. According to the author, it is optimized for high resolution
laptop and widescreen displays.
ratpoison
ratpoison is a free minimalist window manager for the X Window System primarily
written by Shawn Betts. Its user interface and much of its functionality
are inspired by the GNU Screen terminal multiplexer. Its name comes
from the fact that it lets the user manage windows without using the mouse (rat).
Its intended successor is Stumpwm; ratpoison was growing increasingly large,
and Betts decided to largely reimplement its functionality
in Common Lisp.
If you've installed the X Window System in any prefix other than
/usr, become the root
user and update the library linker's cache by adding
/usr/X11R6/lib to /etc/ld.so.conf and running
ldconfig.
Additionally, while still the root user,
ensure /usr/X11R6/bin and
/usr/X11R6/lib/pkgconfig are added to the
PATH and PKG_CONFIG_PATH
environment variables, respectively. Instructions for doing this are described
in the section
The Bash Shell Startup Files.
Ensure you replace /usr/X11R6 with
$XORG_PREFIX in the previous two paragraphs if you
did not create the compatibility symlink in the previous step.
As the root user create a basic X Window
System configuration file with the following commands:
For Xorg:
cd ~ &&
Xorg -configure
For XFree86:
cd ~ &&
XFree86 -configure
The screen will go black and you may hear some clicking of the monitor. This
command will create a file in your home directory, xorg.conf.new
for Xorg, or XF86Config.new
for XFree86.
Edit the newly created configuration file to suit your system. The details
of the files are located in the xorg.conf.5x and
XF86Config.5x man pages. Some things you may want
to do are:
Section "Files". Change the order of the font paths searched. You
may want to put 100dpi fonts ahead of 75dpi fonts if your system normally
comes up closer to 100 dots per inch. You may want to remove some font
directories completely.
Section "Module". If you are going to install NVIDIA drivers, remove
the "dri" line.
Sections "InputDevice". You may want to change the keyboard autorepeat
rate by adding Option "Autorepeat" "250 30".
Section "Monitor". Specify the VertRefresh
and HorizSync values if the system does
not automatically detect the monitor and its values.
Section "Device". You may want to set some of the options available
for your selected video driver. A description of the driver parameters
is in the man page for your driver.
Section "Screen". Add a DefaultDepth statement such as:
DefaultDepth 24. In the SubSection for your
default depth, add a modes line such as: Modes
"1600x1200" "1280x1024" "1024x768". The first mode listed will
normally be the starting resolution.
Test the system with one of the following commands:
For Xorg:
X -config ~/xorg.conf.new
For XFree86:
XFree86 -xf86config ~/XF86Config.new
You will only get a gray background with an X-shaped mouse cursor, but it
confirms the system is working. Exit with Control+Alt+Backspace.
If the system does not work, take a look at /var/log/Xorg.0.log
or /var/log/XFree86.0.log to see what went wrong.
As the root user, create the configuration
directory and move the configuration file to the new directory:
As a convenience, Xorg-7.2 users should populate the
/etc/X11 directory with symlinks to various configuration
directories that were located in /etc/X11 with
previous versions of Xorg. This step is not
needed for XFree86 users. Execute the following
commands as the root user:
This provides an initial screen with a small clock that is managed by a simple
window manager, Tab Window Manager. For details of
twm, see the man page.
... ... ...
Setting up Fonts
There are two font systems in the X Window System.
The first is the core X font protocol, and the second is Xft. Toolkits that
use the core X font protocol include Xt, Xaw, Motif clones and GTK+-1.2. Toolkits
that use Xft include GTK+-2 and Qt and use Fontconfig
for control. Both font systems should be configured for proper font coverage
in the X Window System.
Core X Font Protocol
The core X font protocol finds fonts from the server configuration file
(xorg.conf or XF86Config).
If no font paths exist in the configuration file, the server will fall back
to an internal hard-coded path. Assuming the prefix for your
X installation is
/usr/X11R6, the core fonts will reside in
subdirectories of /usr/X11R6/lib/X11/fonts.
For each directory in the path, the server reads three files:
fonts.dir - maps font files to
font names; updated with mkfontdir
fonts.alias - defines aliases
(such as "9x18") for existing fonts
fonts.scale - lists scalable fonts;
updated with mkfontscale
The core X fonts protocol uses names such as -misc-fixed-medium-r-normal--13-120-75-75-c-80-iso8859-1. These fonts
are rendered by the X server without antialiasing.
The server itself uses the "cursor" font for painting the mouse cursor,
and the protocol specification requires the font "fixed" to be available.
Scalable fonts, such as Type1 and TrueType, are read from
fonts.scale files by the server. The core
X font system uses the "freetype" module for non-antialiased rendering of
these fonts. Ensure that the "freetype" module is loaded in the
XF86config or xorg.conf
file by adding it to the "Module" section:
The character set used is part of the font name, e.g. "-iso8859-1". It
is important that applications which support a non-English interface specify
the character set correctly so that the proper glyphs are used. This can
be controlled through the X resources,
which will be described later.
In some cases, applications rely upon the fonts named "fixed" or something
like "9x18". In these cases, it is important that the
fonts.alias file specifies the correct character
set. Users of ISO-8859-X encodings
where X != 1 should modify the
/usr/lib/X11/fonts/misc/fonts.alias file by
replacing the "iso8859-1" string with the proper encoding name. This is
accomplished by running the following command as the
root user, substituting the proper value
for <X>:
sed -i 's,iso8859-1\( \|$\),iso8859-<X>\1,g' \
/usr/lib/X11/fonts/{75dpi,100dpi,misc}/fonts.alias
Users of Cyrillic fonts have properly defined aliases in
/usr/lib/X11/fonts/cyrillic/fonts.alias. However,
this file will not be used unless the /usr/lib/X11/fonts/cyrillic
directory is first in the font search path. Otherwise, the
/usr/lib/X11/fonts/misc/fonts.alias file will
be used.
Xft Font Protocol
Xft provides antialiased font rendering through
Freetype, and fonts are controlled from
the client side using Fontconfig. The default
search path is /usr/share/fonts and
~/.fonts. Fontconfig
searches directories in its path recursively and maintains a cache of the
font characteristics in fonts.cache-1 files
in each directory. If the cache appears to be out of date, it is ignored,
and information is (slowly) fetched from the fonts themselves. This cache
can be regenerated using the fc-cache
command at any time. You can see the list of fonts known by
Fontconfig by running the command
fc-list.
The X fonts were not installed in a
location known to Fontconfig. This prevents
Fontconfig from using the poorly rendered
Type 1 fonts or the non-scalable bitmapped fonts. Symlinks were created
from the OTF and TTF
X font directories to
/usr/share/fonts/X11-{OTF,TTF}. This allows
Fontconfig to use the OpenType and TrueType
fonts provided by X (which are scalable
and of higher quality).
Fontconfig uses names such as "Monospace
12" to define fonts. Applications generally use generic font names such
as "Monospace", "Sans" and "Serif". Fontconfig
resolves these names to a font that has all characters that cover the orthography
of the language indicated by the locale settings. Knowledge of these font
names is included in /etc/fonts/fonts.conf.
Fonts that are not listed in this file are still usable by
Fontconfig, but they will not be accessible
by the generic family names.
Standard scalable fonts that come with X
provide very poor Unicode coverage. You may notice in applications that
use Xft that some characters appear as
a box with four binary digits inside. In this case, a font set with the
available glyphs has not been found. Other times, applications that don't
use other font families by default and don't accept substitutions from
Fontconfig will display blank lines when
the default font doesn't cover the orthography of the user's language. This
happens, e.g., with Fluxbox in the ru_RU.KOI8-R
locale.
In order to provide greater Unicode coverage, it is recommended that
you install these fonts:
DejaVu
fonts - These fonts are replacements for the Bitstream Vera
fonts and provide Latin-based scripts with accents and Cyrillic
glyphs. The DejaVu fonts by are not aliased to the generic family
names by default, so /etc/fonts/fonts.conf
will have to be edited for it to be recognized by the generic names
such as "Sans". This will be described below.
FreeFont - This set of fonts covers nearly every non-CJK character,
but is not visually pleasing. Fontconfig
will use it as a last resort to substitute generic font family names.
Microsoft
Core fonts - These fonts provide slightly worse Unicode coverage
than FreeFont, but are better hinted. Be sure to read the license
before using them. These fonts are listed in the
/etc/fonts/fonts.conf aliases by default.
Firefly
New Sung font - This font provides Chinese coverage. This font
is not listed in the /etc/fonts/fonts.conf
aliases by default.
Arphic
fonts - A similar set of Chinese fonts to the Firefly New Sung
font. These fonts are listed in the /etc/fonts/fonts.conf
aliases by default.
Kochi
fonts - These provide Japanese characters, and they are listed
in the aliases in /etc/fonts/fonts.conf
by default.
Baekmuk
fonts - These fonts provide Korean coverage, and they are listed
in the aliases in /etc/fonts/fonts.conf
by default.
The list above will not provide complete Unicode coverage. For more information,
please visit the Unicode
Font Guide.
As an example, consider the installation of the DejaVu fonts. From the
unpacked source directory, run the following commands as the
root user:
In this version of X, non-Latin keyboard
layouts do not include Latin configurations as was previous practice. To
set up a keyboard for Latin and non-Latin input, change the XkbLayout keyboard
driver option in the InputDevice section of the XF86Config
or xorg.conf file. For example:
In this example, you can use the Alt+Shift
combination to switch between keyboard layouts and use the Scroll Lock LED
to indicate when the second layout is active.
Setting up XDM
xdm provides a graphical
logon capability and is normally set up in /etc/inittab.
Most of the information you need to customize xdm is found in its man page. To execute
xdm during bootup, change
the initdefault level to 5 and add the following lines to
/etc/inittab:
# Run xdm as a separate service
x:5:respawn:/usr/X11R6/bin/xdm -nodaemon
If Linux-PAM is installed on your system,
you should create a PAM entry for xdm
by duplicating the login entry
using the following command:
cp -v /etc/pam.d/login /etc/pam.d/xdm
Using X Resources
There are many options that can be set in X
and X clients via resources. Typically
resources are set in the ~/.Xresources file.
The layout of the ~/.Xresources file consists
of a list of specifications in the form of
object.subobject[.subobject...].attribute: value
Components of a resource specification are linked together by either
tight, represented by a dot (.),
or loose, represented by an asterisk
(*), bindings. A tight binding indicates that the components on either side
of the dot must be directly next to each other as defined in a specific
implementation. An asterisk is a wildcard character that means that any
number of levels in a defined hierarchy can be between the components. For
example, X offers two special cursors: redglass and whiteglass. To use one
of these resources, you need to add the following line:
Xcursor.theme: whiteglass
However, you can specify the background for all clients with:
*background: blue
More specific resource variables will override less specific names.
Resource definitions can be found in the man pages for each respective
client.
In order to load your resources, the xrdb
program must be called with the appropriate parameters. Typically, the first
time resources are loaded, you use:
xrdb -load <filename>
To add resources to X's database in
memory, use:
xrdb -merge <filename>
The xrdb instruction is
usually placed in ~/.xinitrc or
~/.xsession. To get more information, see
the xrdb man page.
About: Terminator is an application that provides lots of terminals
in a single window, saving valuable screen space otherwise wasted on window
decorations and not quite being able to fill the screen with terminals.
Changes: This release uses a new gnome-terminal gconf key to find
available profiles. A few more hard-coded items have been moved to the settings
array (not that it can be overridden yet). Handling of exiting child processes
has been fixed to properly track gnome-terminal settings. Ctrl-Tab and Ctrl-Shift-Tab
have been added as options for switching terminals. This release no longer uses
parent.show_all() when removing/adding a terminal, and instead shows the actual
widgets that have been created. This prevents scroll bars from re-appearing
after they have been hidden.
This paper provides an introductory look at the X Window System. It is intended
to provide the reader with information in two areas:
A basic understanding of what goes on behind the glass.
Anybody who uses a modern Unix based workstation for scientific visualization
has almost certainly used programs running under X. While little technical knowledge
is required to use today's point-and-click interfaces, a little knowledge about
what goes on behind the scenes can make things less imposing and mysterious.
A general idea of what must be done to implement a portable GUI for a program.
In scientific visualization, like other fields, we are often faced with the
age-old decision to ``build or buy.'' To make reasonable decisions, we must
have a realistic idea of the amount of time required to ``build'' a portable,
graphical program.
Hopefully, this paper will provide readers with a starting point for this
understanding, and make them go back and re-examine existing software packages
should they get the urge to write a custom X11 based program.
xbindkeys, a program that allows you to launch shell commands with your keyboard
or your mouse. Some say it is better that Keylaunch.
If you find xbindkeys a little limited or you hack a lot of scheme for
it, maybe you can have an interest in this
window manager (clfswm).
xbindkeys
is a program that allows you to launch shell commands with your keyboard or
your mouse under X Window. It links commands to keys or mouse buttons, using
a configuration file. It's independant of the window manager and can capture
all keyboard keys (ex: Power, Wake...).
PYWM is a small, simple python-programmable X window manager that's packed
with features, yet very easy to learn and use. It gives you easy-to-use tools
to create your own personal dream desktop. Control Freak Heaven.
Some window managers are mouse heaven and keyboard hell. Other window managers
are the other way around. But PYWM aims to be very comfortable to use from
either.
At the moment PYWM is a "pythonised" version of the fast and light
FLWM window manager,
but it migth grow up and lose all the c(++) code.
So What Can I Do With It?
All sorts of stuff, limited only by your imagination. Here's a short (and very
incomplete) list:
Infinite-sized desktop with keyboard panning (and zooming!!)
Ability to create new desktops on the fly
'Lock' certain windows, so they won't be moved or resized during zooming
or panning.
Move/resize/close individual windows with key bindings
Detect when windows are created/destroyed/moved/resized, and take action
For instance, detect certain applications, and move/resize them when
launched
Set timers, to take actions once or repeatedly
(one of the examples has a function called
'hallucinate' which randomly moves/resizes all the windows on the screen).
Turn window borders and titlebars on and off
Dock unrelated application windows together. Or, if one application
is started, launch another one automatically
Diaplay a different wallpaper when each given window is activated (would
you really want this???)
Have a different set of key bindings for each active window
In addition to this, I'm currently working on an (FLTK-based) API to
allow you to create 'in-window-manager' windows, so you can very easily
build your own applets.
(Also, I'm hoping at some time to incorporate joystick-driven zoom/pan (anyone
wanna volunteer?)
Why???
I've seen dozens of window managers in my time.
At one extreme are the morbidly obese KDE and Gnome desktops, which can take
longer to fire up than Linux itself! One wonders if development of these two
projects is funded by manufacturers of memory and hard disks :p
At the other extreme are hard-core 'minimalist' window managers like 'LWM' and
'TWM', which can be very functionality-challenged, or have some annoying quirks.
For example, one WM I tried requires you to hold down the ALT key while using
the mouse within a window!
On the fringes are 'rodentophobic' window managers like Matchbox, RatPoison,
Ion etc. One thinks of certain people (who will go nameless) who take pride
in still using ASCII dumb terminals.
On the advanced end of the spectrum is the wonderful LISP-driven 'Sawfish' window
manager.
But PyWM is aimed at the middle ground. On one hand, it's easy to set up magickal
key bindings to do pretty much what you want. But on the other hand, it's also
comfortable and courteous for mouse users. I find myself often switching from
mouse/keyboard to straight keyboard, so PyWM is there for me all the way.
And, above all, it's built to support
easy customisation
in Python, the world's
coolest programming
language.
On Tue, 2005-10-04 at 21:13 +0200, Clemens Eisserer wrote:
> Does anybody know a window-manager which is optimized for beeing > programmable and extendable? > The only thing I would like to do is to modify the size of a single > window on an x-server where only this single window is running - > withought simulating mouse clicks or something similar ;-)
Devil's Pie (http://www.burtonini.com/blog/computers/devilspie)
can
manipulate windows when they appear so you can use it to resize the
window. It isn't a window manager so you can use any WM you want.
About: Xming is a port of the X Window System server to Windows. It
shares the same source code base as Cygwin/X, but does not depend on the Cygwin
environment or cygwin1.dll. Xming is a fully featured X11 server for Windows
that is very simple to install and use.
Often it is necessary to change the escape sequences generated by
xterm when function keys are pressed, in order to
match what an application expects. For example, this is very common for Oracle
applications. Here's a way to do this.
Start xterm as follows where the escape sequences
for F1, F2, and F3 have been redefined. Also, start an application called
appl.sh.
Unable to launch any application from command line. The following error message
appears on the console:
Xlib: connection to ":0.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Thu Aug 15 21:29:59 2005 Gtk-WARNING **: cannot open display: :0.0 at (eval 1) line 1.
When we try to run an X11 application, it reads the $DISPLAY variable,
connects to the X11 server (local host, in this case) and provides the magic
cookie by reading ~/.Xauthority
Fixed it by deleting ~/.Xauthority file (that's not a proper
way, of course)
Chris Gerhard
wrote a post last week he called "X11
Forwarding 101" on using xauth to grant permissions to your X display when
you su to root. I was all ready to write
a response about how the complex steps he'd shown could be replaced by a simple,
yet secure, command in Solaris 10 [1]:
If you get an error about xlib refusing a connection to :0.0 while you are
on the console of the machine here is how you can fix it:
The error message will be somthing like this:
xlib: connection to ":0.0" refused by server
xlib: client is not authorized to connect to server
error: can't open display :0.0
The corny thing about this error message is the fact that your sitting
at display :0.0 and using X windows. So you know there is nothing wrong
with the display. All you have to do is type: xhost +localhost
In a nutshell, there are TWO completely different
clipboards implemented in X:
The "select->middle click" clipboard
And the "copy->paste" clipboard
These two clipboards do not affect or interact with
each other.
Other OS's (like Windows) only have the second kind.
Modern Unix applications (like anything based on GTK, QT, or Mozilla)
support both clipboards simultaneously and independently.
Old X Windows applications like XTerm only support
the first kind. This is why you can't copy from or paste into an XTerm
using C-c and C-v.
So if you are using modern applications, you should
always be able to use C-c and C-v. If you have to copy or paste something
into an XTerm, you will have to select it and middle-click. The solution
is to use a moderm terminal, like gnome-terminal, instead of XTerm.
If you read the article, you'll learn that there
are actually three different clipboards in X (one of which is
never used), and that Emacs and XEmacs then implement yet another
fourth clipboard!
Old-style-clipboards in X == drag-and-drop
on Windows/Mac OS. It's just easier to use.
New-style-clipboards n X == copy-and-paste on Windows/Mac OS
Emacs's internal clipboard (the "kill ring") really is an artifact
of the fact that Emacs can run in an environment that lacks
its own copy/paste support (like a VT200, say). Emacs has a
very nice clipboard with a huge history that is generally better
than that of the normal operating environment.
It's rather ironic that people are now complaining that X doesn't
support clipboards persisting past the life of programs -- it
actually *did* at one point with cut buffers, but it's kind
of inefficient when you're working with a remote windowing environment
to immediately dump every cut to the X server.
The real story is why doesn't Linux have a clipboard
standard with well-defined interop standards ala OLE/COM?
I can copy text from VS and paste it into Word, in which case it pastes
as RTF with colors and formatting. If I paste it into notepad, I get
plain text. This is because the clipboard understands high-level text
(RTF) and casting that down into standard text. It also allows apps
to provide multiple data formats; copying an image can put a JPG, Bitmap,
and PNG on the clipboard and the consuming app can select the format
it likes best.
Even better would be to support Office-style multiboard functionality
where there are 10-12 "slots" on the clipboard and you can cut and paste
from each slot at will.
(Ex: in VS, CTRL+SHIFT+V will cycle through each of the last X copied
items for pasting, meaning you can go to one spot of code and copy,
then another and
Xsel is a quick hack to give access to the X selection from the command-line.
by
Ville Herva
You can then copy stuff between stdin/stdout and the X selection buffer.
For example, 'echo puppa | xsel -c' makes "puppa" the current X selection. 'xsel
-p | less' pastes the current X selection to less.
Changes: This version adds the possibility to select between PRIMARY,
SECONDARY, and CLIPBOARD X selection. It adds a --merge action, and incorporates
some code cleanups.
The X Window System was specifically designed to allow the
graphical output of a program running on one machine to appear on a different
machine, possibly one that is physically remote and/or a different make and
architecture. In other words, X11 was designed to be a platform-independent,
networked graphics framework.
In X11 parlance, the "display" denotes the box on which the
graphical output will appear. Interestingly, an individual display is defined
by the X11 documentation as having exactly one keyboard and one pointer (i.e.,
mouse), but potentially multiple CPUs, monitors, etc.
The "screen" corresponds to the actual physical display device;
in most cases this will be a monitor. X11 allows for an arbitrary number of
screens to be connected to each display. Think of a workstation with two monitors
or a departmental server, connected to a larger number of (relatively dumb)
X terminals.
Finally, a "window" is a rectangular area of the screen that
can be used for input and output. If the rectangular area is not directly associated
with a screen, but instead resides in memory, it is referred to as a "pixmap".
Pixmaps and windows share the property of being "drawable" and can be used interchangeably
in some function calls. It is important to remember that to X11 a window is
merely a rectangular area on the screen. As such, it does not include
things like titlebars, scrollbars and other GUI elements that we have come to
associate with the word window. If these elements are present, they are controlled
by a different program called a window manager.
Every GUI-oriented computer ships with a mouse or equivalent.
When X11 came about, the development of graphical input devices was still in
its infancy. Consequently the X11 documentation always speaks (somewhat bashfully)
of a "pointer" (a generic term for mice), trackballs, digitizing tablets or
other yet-to-be-invented graphical input devices. A final cause of confusion
is the specific usage of the words client and server in X11: a "client" is any
application that creates data for graphical output. The "server" is the program
that manages the shared resource accessed by all clients, namely the (finite)
amount of screen real estate. The unfortunate consequence of this naming convention
is that the (X11) client typically executes on the server (machine), while the
(X11) server runs on the client (computer).
Use the xev program that omes with every XFree86 distribution
to get your key's scancodes. The default install location of this program is
in /usr/X11R6/bin/xev. When you run this program you'll be looking at a white
window with a black square in the middle. This program is used to record X11
Events such as mouse clicks, keyboard keys, etc.
Now that you have the program running, try pressing one of
your keyboard's extra function keys. In the terminal from which you launched
xev, the output should be similar to this:
xev output:
----------------------------------------------------------------
KeyPress event, serial 29, synthetic NO, window 0xe00001,
root 0x4d, subw 0x0, time 3608986670, (524,-135), root:(589,304),
state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 characters: ""
KeyRelease event, serial 29, synthetic NO, window 0xe00001,
root 0x4d, subw 0x0, time 3608986842, (524,-135), root:(589,304),
state 0x0, keycode 223 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 characters: ""
----------------------------------------------------------------
Notice that we get 2 events, one KeyPress and one KeyRelease.
The Important part of this event output is the "keycode 223
(keysym 0x0, NoSymbol)" line. By looking at this we can tell a few things. First,
the key's scancode is 223. Second, there is no keysym or symbol assigned to
that key.
What you need to do now is get the scancode for every extra
function key on your keyboard. I suggest you pull out a pen and paper for this
process because if you move the mouse or do anything else while trying to get
the scancode xev will register a bunch of events that we have no interest in.
So make sure to only press the key you want to get the scancode for. Also, make
sure you note which button the scancode was associated with. As an example,
I've included the scancodes I've gathered for my keyboard/
Key Keycode
-------------------------------------------------------
Standby 223
Mute 160
Volume Down 174
Volume Up 176
Play/Pause 162
Stop 164
Prev Track 144
Next Track 153
Email 236
Web Search 229
Run 230
Web Home 178
--------------------------------------------------------
Once Again, this is just an example! Don't use these values
because your keyboard will probably be different than mine.
If you get no output from xev while trying to get your keycodes
that probably means you can't use your keyboard with XFree86 4.0. Some keyboards
might produce weird keycodes that X can't understand.
Giving a Name to your New Keys
Now that you've gathered all your keycodes, we have to give
each one a name in order to assign keysums. This is done in the ~/.Xmodmap file.
That's /home/username/.Xmodmap. If this file does not exist just create it with
your favorite text editor.
You have to put a line for each key in the format "keycode
XXX = keyname". I will list the content of of my .Xmodap file as an example.
The name you give your keys can be whatever you wish, I suggest
giving then a descriptive name in order to avoid confusion. The L prefix in
my example stands for "Logitech" and is just there for my reference. Name your
keys whatever name makes you happy.
Finally Assign Keysysms to the Keys
For the final configuration, we need to assign keysyms to
the keys in order to use them with X. This is done in the XKeysymDB file, located
in /usr/X11R6/lib/X11/XKeysymDB on a default installation of XFree86 4.0. You
must be root to edit this file.
Here's my additional entries in the XKeysymDB file for my
keyboard:
Once done, save that file and restart X. Start xev once again
to verify your setup. Now if you follow the instructions in the first step again
to get the scancodes of your keys, you'll notice that there is now a keysym
and Symbol assigned to your key. If that was successful, you can now assign
those keys to shortcuts or to launch programs. This is done differently with
every window manager, so I won't go trough the process; check your window manager's
documentation on how to assign shortcut keys.
Gateway - 2001-02-23 23:14:28
Unfortunately, my Gateway PC's keyboard sends a series of signals. So when I
hit the 'Pause' button at the top I get ctrl-meta1-alt-p or something.
Also, I found jwz's xkeycaps utility to be very useful. Still can't use my keys
as I want to, but I did get it to find out what was going on in a much easier
fashion than xev...
X already has quite a few... - 2001-02-23 18:03:54
This can done also by using the files in /usr/X11R6/lib/X11/xkb/symbols. For
example, the Logitech iTouch is in the inet file. This can be loaded with setxkbmap
file section
where file is the file in the above directory, and section is the type of keyboard
you have. This will then give you symbols such as XF86Mail, which can the be
mapped in the window manager. One problem with this is that KDE 2 doesn't like
these.
Another way to do this is using hotkeys (do a search of freshmeat). Along with
libosd (find from the hotkeys homepage). This will work independently of the
window manager.
So you're new to Linux and wondering how this virtual terminal
stuff works. Well you can work in six different terminals at a time. To move
around from one to another:
To change to Terminal 1 - Alt + F1
To change to Terminal 2 - Alt + F2
...
To change to Terminal 6 - Alt + F6
That's cool. But I just did locate on something and a lot of stuff scrolled up. How do I scroll up to see what flew by?
Shift + PgUp - Scroll Up
Shift + PgDn - Scroll Down
Note: If you switch away from a console and switch back to it,
you will lose what has already scrolled by.
If you had X running and wanted to change from X to text based
and vice versa
To change to text based from X - Ctrl + Alt + F(n) where n = 1..6
To change to X from text based - Alt + F7
Something unexpected happened and I want to shut down my X
server.
Just press:
Possible the greatest work of literature ever written about X. Guaranteed
to entertain you for several minutes at least. I think he hangs around /. as
well. Just get him started on the topic. :)
Really, it's solid stuff. Think about it, instead of having a knee-jerk reaction.
You're wrong about your "Windows-convert/Machophile"
accusation. I wrote it long before I learned to program Windows or the
Mac. (Or did you really mean Mach?) At the time, I was a disgruntled
ex Sun employee. "Slowlaris: So bad I left the company."
Nobody's blaming X itself for the mistakes of its
designers. I'm blaming ignorant hypsters like yourself for all the insincere
uninformed cheerleading that led to the widespread adoption of X11,
in spite of all of its severe technical problems. Stop being such an
appologist for bad design and poor execution.
I tried to make constructive criticism in that chapter,
comparing it to NeWS's downloadable code and extensible protocols. NeWS
was certainly not perfect, but X11 had a lot to learn from it, and people
like you still refuse to open your eyes to that fact.
The software we're using today has evolved into a
model much closer to NeWS than X11. Web servers are like NeWS clients
(the program that runs an application remotely). The web browser is
like the NeWS server (the program running on the user's machine), that
controls the display. The web server can download html and javascript
to the browser, that interacts locally with the user, much in the same
way that NeWS clients download PostScript code to the NeWS server.
So before you tell me that NeWS's model of downloadable
extensibility sucks and nobody uses it, you should do some research
and check out that new craze that everybody's been talking about recently,
called the world wide web. If you have never heard of the web, and can't
find a book about it in the library or your local book store, just search
for "www" on yahoo.
Well, the reason why X Window is
so deeply rooted in the UNIX world is that, to quote one of my friends,
"There are no fucking attractive alternatives!". I agree that X is a
nightmare and should be killed off by a better competitor, but there
is no better competitor.
And BTW, X has plenty of problems but user interface inconsistency is
not one of them. X is low-level and user interface standards are clearly
not in its domain. The fact that, say, a middle mouse click can do anything
at all in an X application is not a drawback of X -- it's a side effect
of the UNIX world being fragmented, idiosyncratic, and, yes, free to
do whatever one wants.
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
Unfortunately, this particular baby's grown into an immense, slimy,
tentacled beast that's strangling the development of graphical technology
on Unix.
I would like to note that I don't agree with some of the criticisms
in the article -- for example, I think the componentization of the Window
manager and various other items is generally a Good Thing. X wouldn't
have survived as long as it has if something like the 80s-era window
managers were part of the standard server.
While X has a lot of good points (network transparency, platform independence,
flexibility in window management), those doesn't make up for its defects.
It IS possible to design systems with these characteristics that don't
have the downsides that X does.
The underlying X protocol is incredibly clean and extensible, but there
are now so many (effectively mandatory) extensions that the code required
to support them makes the X server software absolutely huge. ICCCM is
a nightmare in its own right.
Moreover, many of these extensions/auxiliary protocols (a prime example
would be the X font system) were not designed in the same forward-looking
manner as the basic X protocol, meaning that it is necessary to replace,
rather than enhance them. However, since existing software still relies
on the old extensions, it's not possible to drop them -- you end up
with even more redundant code bloat.
X doesn't really give you any choice with regard to widget toolkits,
either. You're stuck with the one the app was compiled with, or, more
often, coded soley against.
With an architecture like Berlin (or a number of others), it's possible
replace the widget set in any or all all apps with the one of your choice
-- on the fly.
There's also the problem that EVERY primitive operation in X requires
the request to be marshalled/demarshalled across process boundaries.
The address space separation (and consequent easy network transparency)
between client and server is not a bad thing, IMO, as it helps stability,
but I belive the X designers made a fundamental mistake when they cut
the client/server boundary at such a low level.
Having to do this sort of low-level chatting across process boundaries
really hurts performance.
Architectures like Berlin maintain the client/server separation, but
cut down on the performance hit by communicating at a significanty higher
level of abstraction. This means a decently-written Berlin app, even
if using a chunky protocol like IIOP, would create significantly less
IPC traffic (in bytes) than the equivalent X app.
Of course X has DGA. X has shared memory. Unfortunately, those only
work locally. If you rely on them, you just shot network transparency.
Whoops.
And, there's another problem: instead of writing graphics drivers independent
of any one application class or GUI architecture (which means basic
kernel support), everyone's been writing drivers directly for the X
server. (Thanks, XFree86!)
This means that to even reach a usable stage, every non-X project has
to rewrite their own driver suite from scratch (as a rule, X drivers
make too many assumptions about X for the code to be readily reusable
for other things).
Although we have fbcon now, fbcon is pretty much unaccelerated, and
doesn't have that broad a range of hardware coverage. Berlin is still
mostly tested on top of X as a result.
If you have to keep X around to run Berlin, or face severely reduced
hardware support, then what's the point?
X has been repeatedly marginalizing other graphical efforts this same
way. (Who here has heard of Y Windows, for example? How many of you
know someone who uses it? What hardware does it support?)
Thankfully, due to GGI, Berlin can run on fbcon and KGI -- if KGI ever
becomes more widespread, Berlin might finally be able to break free
of X.
It's time we stopped relying on the X server for everything graphical.
It's too late to throw out the bathwater, baby or no. It's outgrown
the bathtub and eaten your dog.
Brian
Hammond's X11 Pages: Another personal X11 page with a tutorial, containing
a little bit more information than Tronche's tutorial but less organized.
XFree86 Version 4.1.0:
The official page for the current release of the open-source version of the X Window
System. At the bottom of the page one finds the complete set of man pages.
Xlib Programming Manual by Adrian Nye. Volume 1 of the X Window System
Series at O'Reilly. The book is wordy (it needs three chapters and almost 80 pages
to cover not much more material than the present article), and the presentation
is not always noted for its clarity. Nevertheless, it is probably still the standard
introduction to X11 programming.
X Window Applications Programming by Eric F. Johnson and Kevin Reichard.
One of the few truly introductory books on X11 programming
Note that some of these groups, especially those not in the comp.*
hierarchy, may not be universally available. Contact your system administrator for
more information.
Note: an alternative (and usually much cheaper) way to run X on a IBM PC is to
run a PC UNIX in place of or in addition to your Microsoft OS.
See the previous solution for more information.
This web site lists only the basic X products, such as X servers, Motif, and
CDE. The following pages have (much) more information on commercial and non-commercial
X-based applications and products.
Many of these contain more listings of X-related sites. These overlap with this
page, but you may find their organization of the material to be useful. See also
the FAQs for more X-related links.
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
Download an appropriate Nvidia driver for your VGA card. Alternatively, if you know what you are doing you can download the driver directly from the Nvidia Linux driver list . Once ready you should end up with a file similar to the one shown below:
$ ls NVIDIA-Linux-x86_64-* NVIDIA-Linux-x86_64-460.39.runWhen prompted answer
Allow automatically update of your X configuration file.
You should see the following message after successful NVIDIA driver installation.
