Remote display: Difference between revisions
Line 63: | Line 63: | ||
ssh olpc@xo-ip-address -C -X /home/olpc/remotedisplay |
ssh olpc@xo-ip-address -C -X /home/olpc/remotedisplay |
||
== Cloning a current Sugar session == |
== Cloning a current Sugar session (using VNC) == |
||
Note: This method does not allow mouse or keyboard input on the remote display (unless you explicitly enable it as per [[#Enabling Keyboard and Mouse|below]]). |
Note: This method does not allow mouse or keyboard input on the remote display (unless you explicitly enable it as per [[#Enabling Keyboard and Mouse|below]]). |
||
Revision as of 17:05, 9 March 2008
- This describes how to control/display your non-XO-computer via your XO. To display the XO's screen on another monitor, see Reverse remote display
If you are trying to project the user interface of an XO laptop, this page is for you. It describes how to bring up the user interface of an XO laptop (the source computer) across the network on another computer running X11 or Windows (the display computer). Three methods are described below. The first method lets you run a remote Sugar session on the display computer. Using the second method, the current Sugar session is cloned to the display computer. The third method (which isn't actually using the network) requires a soldering iron.
First method: direct output, via USB or VGA
Using recent Operating Systems, it is easy to make a USB2VGA adapter work with your XO. Using USB2VGA adapters has some limitations (see below for details).
Selecting the right USB-SVGA adapter
Short version: The devices tested and known to work are
While in general, this feature works with USB-SVGA adapters based on the SIS Net2280/SiS315 chipset, which uses the 'sisusbvga'(kernel) and 'sisusb'(xorg) drivers, only those two models have been reported to work. Other devices from Startech.com are available, with similar model names, but you should not expect them to work.
For more details, see the author's page here. Some devices reported to work according to the NSLU2 wiki
Using lsusb, we have seen these identifiers on devices that work:
Bus 004 Device 005: ID 0711:0900 Magic Control Technology Corp. SVGA Adapter
On XO OS 10.1.3 and newer
Just plug the USB2VGA device to the XO, and start it up (or restart it if it is on). The desktop will only appear on the external display. The LCD of the XO will not be operational.
On XO OS 10.1.1 and 10.1.2
You will need to install some required modules from the main repositories
yum install xorg-x11-drv-sisusb
And the RPM containing the required auto-configuration scripts
wget http://dev.laptop.org/~martin/public_rpms/f11/olpc-utils-1.0.31-1.fc11.i586.rpm
rpm -Uvh olpc-utils-1.0.31-1.fc11.i586.rpm
Connect the USB SVGA adapter, and restart your XO.
On XO OS 8.2.1 and earlier
The process is more complex as you will have to compile kernel and xorg modules. See Adding_USB_SVGA/Fedora_9_and_earlier
Limitations and quirks
- No mirroring, external display only. When you are using the USB VGA device, we disable the internal LCD screen. This is for two reasons
- Performance is bad when trying to drive the 2 screen simultaneously. This is in part because the internal display is very differentrom a conventional screen.
- On XO-1, the OS releases based on Fedora 11 (the 10.1.x series) cannot run both the internal video card and a SiS USB device.
- Sometimes changes are not shown on screen immediately. Move the pointer to get the external display updated. There is a bug in the SiSUSBVGA driver that "forgets" to update the screen. We are investigating.
- When using the USB SVGA device, power saving mode is disabled so you battery will drain faster.
- Performance is slower.
- Some activities (for example Pippy) do not work or display correctly on the "smaller" screen.
- There may be a visible difference in color temperature
- Earlier than 10.1.3 the kernel module may be missing in some OS/XO model combinations -- compile the kernel and modprobe sisusbvga.
Pictures
Here are some pictures of the OLPC working with the USB-SVGA adapter.
Other Resources
- See Remote display for other ways to connect a second display to an XO.
- For alternate linux distributions, see this thread
- Experimental: DisplayLink
Hacking into the on-board VGA output
While on Gen1 XO laptops (the B1/B2/B3/C1/MP builds) it will continue to be possible to attach a VGA connector to the XO motherboard, making use of it requires soldering a jumper (pins 1 and 3 of CN18) and cutting the laptop case to make room for it. In B3/C1/MP versions, additional required passive components will not be populated on the motherboard (but are easier to obtain than the required VGA connector!)
Caveats :
- One problem with this approach (on B2, but not B3/C1/MP machines) is a weird gamma correction currently applied by software to fix a hardware wiring error.
- An additional problem is that many displays are very unhappy with the 1200x900 resolution video output by default by the XO laptop.
Second method: remote and cloned Sugar sessions
Remote Sugar session (using X11)
Preparations
Note: This method of access can be very slow
There are some harmless changes to the XO which only need to be done once. You will need to assign a password to the olpc user, and create the script which is remotely executed to start Sugar.
To assign a password to the laptop user, obtain a console window, either through the debugging interface accessed by alt + "=", or by bringing up a console with ctl + alt + (ctl + alt + F1 on a PC keyboard). Become root and change the password by typing:
su passwd olpc exit
Now go to the laptop user's home directory, and create the script which will start sugar:
cd /home/olpc cp /usr/bin/olpc-session remotedisplay chmod a+x remotedisplay
Stopping Sugar on the XO
Due to current limitations of Sugar, there can only be one copy of Sugar running on any given XO. This will mean that you need to shut down Sugar and X on the XO from which you want to forward the user interface. There are several ways you can do this, but the simplest (and temporary) way is to first change to the console, by typing control + alt + F1 (Eye). Log in as root, then change the runlevel of the XO to runlevel 3 by typing:
init 3
After doing this, the XO should still be associated with any wireless network it already found, but it will have forgotten about its IP address. You need to manually request an address using:
ifup eth0
If this doesn't work because you aren't associated with a wireless network, you can manually bring up the network using:
iwconfig eth0 essid "some local wifi SSID" ifup eth0
You can get a list of the local WiFi networks using
iwlist s eth0
Check the network address assigned to the XO by DHCP, as you will need it for the next steps.
ifconfig eth0
Bringing up the display remotely
At this point, you will need a version of X on the display computer which is running bare (no display or session manager). The easiest way seems to be to create a new user on the display computer, and give them an .xinitrc (or .xsession file under Debian) which consists simply of:
ssh olpc@xo-ip-address -C -X /home/olpc/remotedisplay
Cloning a current Sugar session (using VNC)
Note: This method does not allow mouse or keyboard input on the remote display (unless you explicitly enable it as per below).
The trick is to install RealVNC, and run x0vncserver on the XO computer. The display computer runs a vncviewer that clones the XO display. (Note that this method will not work yet when the laptops are in mesh mode—we need to do packet-forwarding on the School Server to enable the vnc connection. Until then, put the laptop in infrastructure mode by using an access point for your network access. If you want to project from a machine running Linux with a recent kernel, you can compile the Marvell driver on it and add an 8388 dongle in mesh mode to communicate with XOs in the mesh.)
Preparations
You have to fetch and install the vnc-server on the XO computer. Login as root to a shell, and run the following:
rpm -i -v --nodeps ftp://rpmfind.net/linux/fedora/core/updates/6/i386/vnc-server-4.1.2-9.fc6.i386.rpm
You can search for a newer package at rpmfind.net.
Now, login as an olpc user and create a password for vnc sessions.
cd /home/olpc vncpasswd
Create an activation script for the x0vncserver, still as olpc user, using vi or nano or cat:
File: ~/x0server |
#!/bin/sh nice -19 x0vncserver PasswordFile=/home/olpc/.vnc/passwd AcceptPointerEvents=0 AcceptKeyEvents=0 & disown |
The x0vncserver must run very very nicely (nice -19), since otherwise it takes all available CPU and leaves no room for other processes to run. The last two options of the x0vncserver (AcceptPointerEvents and AcceptKeyEvents) runs the server in a "view only" mode.
Don't forget to make the script executable.
chmod a+x /home/olpc/x0server
Alternately...
x11vnc is also known to work, does not require messing with passwords, and will allow mouse movement input, but still no mouse buttons or keyboard (but see end of section on how to enable these). This can be achieved as follows:
yum install openssl097a rpm -i ftp://rpmfind.net/linux/dag/fedora/3/en/i386/dag/RPMS/x11vnc-0.8.3-2.fc3.rf.i386.rpm
Note, if rpm gets an unexpected error in the middle, you may have too many activities running (not enough memory?). Try closing everything but the Terminal window. After the yum and rpm steps complete successfully, simply running 'x11vnc' on the laptop (e.g., via terminal or through ssh session) will open a password-less VNC session to which to connect with vncviewer. The openssl097a package is required to satisfy some of the dependencies of x11vnc.
Just before the presentation
The XO computer and the display computer should be on the same Wifi network (or, depending on the Wifi network there, stability may be better off connecting via Ethernet: XO - USB ethernet adaptor - ethernet cable - USB ethernet adaptor - other laptop hooked up to projector). You will need to know the IP of the XO computer (run /sbin/ifconfig eth0 if you don't know it). Now, from within Sugar, open a console (Alt-0 or Alt-=), and run the /home/olpc/x0server script you have prepared in advanced.
/home/olpc/x0server
It will write to the console; then you can close the console.
main: XTest extension present - version 2.2 main: Listening on port 5900
In the display computer, run the vnc client/viewer.
vncviewer xxx.xxx.xxx.xxx FullScreen=1 ViewOnly=1
or, on some clients,
vncviewer xxx.xxx.xxx.xxx -fullscreen -viewonly
Where xxx.xxx.xxx.xxx is the XO computer IP address.
In order to close the vnc viewer, press F8 in the displaying computer. This is the escape key which gives you a context menu with various options. You can change the full-screen mode, exit the viewer, and set other options as well.
Caveats
- Modifying WiFi: Whatever you do, don't click on the WiFi signal strength when using the remote display. Even if you select the network you are already using, you will freeze the display.
- 'Screen resolution : The vnc server dies when the resolution is changed. You will have to restart the server and the client if the screen orientation is changed.
Enabling Keyboard and Mouse
By default, the XTEST extension is disabled for security reasons. To enable keyboard and mouse usage through a VNC connection, you can enable the XTEST extension by modifying /etc/X11/xorg.conf, changing the line:
Option "XTEST" "Disable" # Mostly a debugging tool
either by commenting it out:
# Option "XTEST" "Disable" # Mostly a debugging tool
or explicitly enabling it:
Option "XTEST" "Enable" # Mostly a debugging tool
Be sure to omit the '-viewonly' option to vncviewer when connecting.
Simple emulation (no XO required)
Given a proper network (fast DSL/LAN) and a fast qemu server your presentation can be fast and authentic.
Server side
First start the qemu session on the host:
qemu -kernel-kqemu -vnc 0 -k en-us olpc-redhat-stream-development-devel_ext3.img
The flag -vnc 0 tells qemu to direct the VGA output to the VNC session 0.
Next connect with a proper VNC viewer on your laptop/PC which has the VGA output .
client: Mac OS X
On Mac OS X Chicken of the VNC can not properly handle the VGA output of the qemu emulation. So, instead use VNCviewer Direct VNCViewer to your host running the qemu instance and set it to fullscreen. Voila! You should have a much faster remote access possibility than with X11 forwarding.
client: Windows
Use UltraVNC:
Please note that sometimes with UltraVNC you have to play around with the speed settings so that the screen does not refresh all the time to fast.
client: Linux
you know your stuff anyway. Use vncviewer from apt or yum --AaronKaplan 21:45, 17 June 2007 (EDT)