*Ubuntu 10.04 installed on a 80gig 3.5 IDE drive. The generic install works fine out of the box, but optimizations for an older memory and speed limited system would never hurt.

+

** 2011-10-02: upgrade to 11.04 in progress

−

====to do====

+

===To Do===

−

#make list above more specific

+

* Cant get the openchrome Xorg driver to work well with the VIA eden board. The Ubuntu package is called xserver-xorg-video-openchrome. xorg.conf was modified to use the 'openchrome' device and dpkg-reconfigure -phigh xserver-xorg was run. Then gdm was cycled by /etc/init.d/gdm restart

−

# It needs some Zytouch driver love, which may come from here: http://www.mega-nerd.com/erikd/Blog/CodeHacking/zytouch-driver.html

+

+

+

#A round tabletop system presents challenges to window management designer, it would be interesting to get a touch based system like Android running on this machine. The machine may be down for work on projects like this.

+

# It needs some Zytouch driver love, which comes from the touch-base website: http://touch-base.com/documentation/LinuxPlatformNotes.htm#_Serial_port_issues

+

# The serial connection has been routed through a keyspan 19HS serial-to-USB converter. Unfortunately, drivers for the damned thing are only available for Windows, and John has been bashing his head against getting the Ubuntu host to recognize the converter and pass the serial connection through to wine. Windows may need to be installed.

+

# Another option is to reverse engineer a driver. This could theoretically be a userland daemon providing an input device to Xorg. There are many ways to help this effort:

+

+

Here is a hex dump of the serial data sent by the touchpad with "no interaction": http://pastebin.com/wmCaQMdK

+

+

I can't guarantee that the output represents _zero_ interaction because some values in the stream appear to be _very_ sensitive to proximity.

+

+

There are 11 or so unique values sent from the touchscreen. We have to figure out what they mean and when they are sent.

+

+

If you want to have a look at those values, open the homebrew "driver" in the works: ~/noisetap/noisetap.c

+

+

There you will find the list of values and the best explanations we can come up with as to what they mean.

+

+

Another way to help out would be to bring a Windows box with a serial connection to the table (see what I did there?). If you can get the touchscreen driver to work, we may be able to step through the driver code and reverse engineer it that way. This would probably be a lot easier than figuring it out from the raw data dump, but it requires some Windows know-how (That's a tough thing to find at Noisebridge). If you want to lend a Windows box to the project, John will gladly take care of the gory details involved in DLL sniffing (or whatever it is we need to do).

+

+

This link may or not be helpful on data format, but this guy RE'd a different model over USB... -> http://www.mega-nerd.com/erikd/Blog/CodeHacking/zytouch-driver.html

+

+

== How to reset the BIOS video settings ==

+

+

While playing around with the BIOS settings, I ended up disabling the built-in LCD from working anymore. Problem was, I couldn't see the BIOS screen to reset it! I ended up taking the table apart in order to find the VGA out connector. Plugging an external monitor to this allowed me to see what I was doing, at least part of the time. There were other times when even the BIOS screen appeared garbled. Here are the steps to reset the screens back to normal...

+

+

'''This is what we want to set in the BIOS to restore the LCD:'''

+

* Advanced Chipset Features

+

** AGP & P2P Bridge Control

+

*** Panel Type

+

**** set to "1280x1024 2x24B"

+

+

+

* Problem is, just setting the above won't immediately fix the LCD. Try setting first to "1024x768 1x18B", save and reboot, then set to above resolution.

+

+

* Make sure "Display Device" is set to "CRT+LCD" prior to setting the above. (CRT is the VGA out, LCD is the built-in monitor)

+

+

+

'''Steps to restore monitors while working blind:'''

+

+

# On boot, press "del" key a few times right after colored lines on LCD flash to get into BIOS.

After reseting the BIOS to minimal failsafe defaults, the CPU is reset to 400 MHz. The CPU can actually go much faster. Reseting the BIOS using the Optimal Defaults will reset the CPU to it's full 1GHz. Resetting the defaults will disable the monitor though, so I wouldn't recommend doing this.

+

+

Instead, I changed the CPU frequency settings to an x8 multiplier instead of the minimal x4, which doubled the CPU's clock to 800 MHz. This appears to work just fine, and is what the CPU is currently set to.

+

+

+

== Getting basic video to work in X11 ==

+

+

To configure X11 to work with the basic VESA video driver:

+

sudo cp ~/carl/backup/etc/X11/xorg.conf /etc/X11

+

+

Or enter the following in /etc/X11/xorg.conf:

+

<pre>Section "Device"

+

Identifier "Configured Video Device"

+

Driver "vesa"

+

EndSection

+

+

Section "Monitor"

+

Identifier "Configured Monitor"

+

EndSection

+

+

Section "Screen"

+

Identifier "Default Screen"

+

Monitor "Configured Monitor"

+

Device "Configured Video Device"

+

EndSection

+

</pre>

+

+

* Then run:

+

sudo dpkg-reconfigure -phigh xserver-xorg

+

sudo /etc/init.d/gdm restart

+

+

* Currently uses "vesa" driver. Have not been able to get "openchrome" to work yet.

Cant get the openchrome Xorg driver to work well with the VIA eden board. The Ubuntu package is called xserver-xorg-video-openchrome. xorg.conf was modified to use the 'openchrome' device and dpkg-reconfigure -phigh xserver-xorg was run. Then gdm was cycled by /etc/init.d/gdm restart

A round tabletop system presents challenges to window management designer, it would be interesting to get a touch based system like Android running on this machine. The machine may be down for work on projects like this.

The serial connection has been routed through a keyspan 19HS serial-to-USB converter. Unfortunately, drivers for the damned thing are only available for Windows, and John has been bashing his head against getting the Ubuntu host to recognize the converter and pass the serial connection through to wine. Windows may need to be installed.

Another option is to reverse engineer a driver. This could theoretically be a userland daemon providing an input device to Xorg. There are many ways to help this effort:

I can't guarantee that the output represents _zero_ interaction because some values in the stream appear to be _very_ sensitive to proximity.

There are 11 or so unique values sent from the touchscreen. We have to figure out what they mean and when they are sent.

If you want to have a look at those values, open the homebrew "driver" in the works: ~/noisetap/noisetap.c

There you will find the list of values and the best explanations we can come up with as to what they mean.

Another way to help out would be to bring a Windows box with a serial connection to the table (see what I did there?). If you can get the touchscreen driver to work, we may be able to step through the driver code and reverse engineer it that way. This would probably be a lot easier than figuring it out from the raw data dump, but it requires some Windows know-how (That's a tough thing to find at Noisebridge). If you want to lend a Windows box to the project, John will gladly take care of the gory details involved in DLL sniffing (or whatever it is we need to do).

While playing around with the BIOS settings, I ended up disabling the built-in LCD from working anymore. Problem was, I couldn't see the BIOS screen to reset it! I ended up taking the table apart in order to find the VGA out connector. Plugging an external monitor to this allowed me to see what I was doing, at least part of the time. There were other times when even the BIOS screen appeared garbled. Here are the steps to reset the screens back to normal...

This is what we want to set in the BIOS to restore the LCD:

Advanced Chipset Features

AGP & P2P Bridge Control

Panel Type

set to "1280x1024 2x24B"

Problem is, just setting the above won't immediately fix the LCD. Try setting first to "1024x768 1x18B", save and reboot, then set to above resolution.

Make sure "Display Device" is set to "CRT+LCD" prior to setting the above. (CRT is the VGA out, LCD is the built-in monitor)

Steps to restore monitors while working blind:

On boot, press "del" key a few times right after colored lines on LCD flash to get into BIOS.

After reseting the BIOS to minimal failsafe defaults, the CPU is reset to 400 MHz. The CPU can actually go much faster. Reseting the BIOS using the Optimal Defaults will reset the CPU to it's full 1GHz. Resetting the defaults will disable the monitor though, so I wouldn't recommend doing this.

Instead, I changed the CPU frequency settings to an x8 multiplier instead of the minimal x4, which doubled the CPU's clock to 800 MHz. This appears to work just fine, and is what the CPU is currently set to.