[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600

Please attach your /var/log/Xorg.0.log.

Just to be safe, could you specify which version of the AMD driver you're using?

It is falling back on the VESA driver instead of the xserver-xorg-video-amd.

Martin-Eric, could this have anything to do with the pci rework in the driver? I know that it was all properly #ifdef'd when I reviewed, but perhaps something got missed? (Just a guess.)

Here's the pci id's for this hardware:

(--) PCI:*(0:1:1) Advanced Micro Devices [AMD] Geode LX Video rev 0
(II) PCI: 00:01:1: chip 1022,2081 card 1022,2081 rev 00

Bryce, I have received numerous reports from other sources as well on this issue. Their BIOS seems to be among the buggy ones that might require workarounds in x86emu. It was already the case before the PCI rework.

FYI, I have just contacted Koolu, asking for their direct participation in resolving this issue.

Hardy 8.04 Daily (20080409) installed.
Usplash issue is still there but this time, the status bar ends up being overplayed on top of itself and visually mixed up.
Installed http://people.ubuntu.com/~ogra/xserver-xorg-video-geode_2.8.0-5_i386.deb
Forced geode driver installation to overwrite files which were installed by the amd driver.
Attempted restarting X, running "X -configure" and running "displayconfig-gtk" to change the driver.
None of these automatically set up greater resolutions or fixed usplash issues.
Rewrote xorg.conf file to use driver for VGA controller.
Does not seem to correct any issues.

displayconfig-gtk displays confusing information:

Graphics card (VESA driver (generic))
Driver: geode
Video Memory: Automatic

Thanks Martin,

Is there anything further I could do to help this along? (I don't know
anything about x86emu internals and don't have the hardware on hand, but
if there is any packaging chores needed, I could assist.)

Bryce

On Wed, Apr 09, 2008 at 12:11:38PM -0000, Martin-Éric Racine wrote:
> FYI, I have just contacted Koolu, asking for their direct participation
> in resolving this issue.
>
> --
> [HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600
> https://bugs.launchpad.net/bugs/214119
> You received this bug notification because you are a member of Ubuntu-X,
> which is subscribed to xserver-xorg-video-amd in ubuntu.
>
> Status in Source Package "xserver-xorg-video-amd" in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: xserver-xorg-video-amd
>
> VGA Controller is an AMD Geode LX (should be using installed xserver-xorg-video-amd 2.7.7.7-1)
>
> Not sure what video driver is being used, please include instructions to check this in Hardy.
>
> Maximum resolution is 800x600

Installation error. To correct, ran
dpkg -i --force-all xserver-xorg-video-geode_2.8.0-5_i386.deb

The installation error I've mentioned on bug 211385 as needing fixed before we accept -geode into Ubuntu.

From the Xorg.9.log, it appears that GEODE is getting properly detected and loaded:

(II) GEODE: Driver for AMD Geode Chipsets: Geode LX, Geode GX
(II) Primary Device is: PCI 00:01:1
(II) AmdProbe: Probing for supported devices!
(II) AmdProbe: Before MatchPciInstances!
(--) Chipset Geode LX found
(II) AmdProbe: MatchPCI (1)!
(II) AmdProbe: CPUDetected 32!
...
(--) GEODE(0): Virtual size is 1792x1344 (pitch 1792)
...
(==) GEODE(0): DPI set to (96, 96)
...
(II) EXA(0): Driver registered support for the following operations:
(II) Solid
(II) Copy
(II) Composite (RENDER acceleration)
(==) GEODE(0): Backing store disabled
(II) GEODE(0): DPMS enabled
...
(--) RandR disabled
...
(II) AIGLX: Screen 0 is not DRI capable
...
(WW) GEODE(0): xf86UnMapVidMem: cannot find region for [0xb593c000,0x1e00000]

The lack of Xrandr is troubling, since that will make screen configuration less easy (I'm assuming it just hasn't been implemented yet for -amd). It sounds like DRI wasn't enabled either, although EXA seems to have loaded ok. I'm not sure what to make of that final warning, but it sounds like something that should be looked into upstream.

David, can you please test using the attached xorg.conf?

Bryce, I have tested it with your xorg.conf and the maximum resolution is still 800x600 and the usplash is still garbled. I know for a fact that this unit goes up to 1920 x 1440, yet with the current configuration (8.04 Daily + xserver-xorg-video-geode_2.8.0-5) I can't get resolution greater than 800x600 without going off screen. The standard set of resolution available through Monitor Resolution Settings is 800x600 and 640x480.

Please let me know what you would like me to try out next.

Confirmed on an Artec ThinCan DBE61 also.

This seems to be a regression from AMD 2.7.7.7, which worked fine.

Does the ThinCan also have the following line in Xorg.0.log?
(II) GEODE(0): VESA VBE DDC read failed
It seems that the BIOS VBE DDC on the Award BIOS is either non-
existent or broken, hence failing on the Koolu WE/ION A603..

Jordan Crouse mentioned about adding support for libDDC that would use
the i2c protocol to interface with the monitor directly instead of
going through the BIOS. This would remove all BIOS dependencies for
detecting the proper monitor modes. This feature is slated for June.

Brian

Hmm... Pretty weird! A few hours later and everything works as it should, DDC and all, on this ThinCan, with either AMD 2.7.7.7-1 or GEODE 2.8.0-1 (available via my PPA).

Please test the packages in my PPA at:

deb http://ppa.launchpad.net/q-funk/ubuntu hardy main
deb-src http://ppa.launchpad.net/q-funk/ubuntu hardy main

Those contain an experimental patch from AMD that bypasses the BIOS completely and instead uses the X.org libddc to directly poll the display.

Please let the release manager know ASAP if this package solves this issue or not. We have less than 24h left to get any change into Hardy. Otherwise, the upload will move to the next Ubuntu release.

Unfortunately, this patch completely prevents X from launching on a ThinCan DBE62 (LX800, General Software BIOS). We don't get any display output whatsoever. Reverting to 2.8.0-7 (without patch) restores display output and DDC support.

We are not at all ready for this patch to go into production systems. Please remove your test packages immediately - I'm afraid we have officially lost the race to get into Hardy.

Test packages won't go into Hardy. They are in a separate repository. It just makes it easier for people to do A/B testing.

After re-generating the Makefile.in and rebuilding, I finally got this experimental patch to work on my ThinCan DBE62.

Updated packages are available in my Personal Package Archive at the URL above, for those who want to test this and compare with the current Hardy package. Among other things, this test package should finally make X auto-configuration work on Geode hardware that boots off Coreboot.

1) Attach your X log and we can be sure that you are using the resolution that the monitor reported. This is one of many problems with DDC/EDID. People don't realize that there isn't a connection between what the display controller can do, what the monitor can do, and what the monitor reports that it can do. When you chose to use DDC, then you are blindly restricted to what the monitor tells you to use. You *can* use other resolutions, but that will involve hacking an xorg.conf file.
2) Xorg -configure works from the GIT tree, so the driver and the X server agree on probing the PCI ID at least. I'm not sure how the detection and installation works in Ubuntu, so somebody more knowledgeable then myself will need to evaluate that.
3) That is kernel based breakage - it has nothing to do with the X driver
4) Ditto.

Unfortunately, this patch _is_ our simple workaround - all other workarounds are far more complex. But I do agree this patch needs more far more testing - it is still some time away from being added to the GIT repository, let alone making it into any distros.

On Thu, Apr 17, 2008 at 8:10 PM, David Bensimon
<email address hidden> wrote:
> This is much better, but there are still a few issues:
>
> 1) After installing the geode driver (2.8.0-7) I am able to reach resolutions up to 1280x1024 @ 60Hz (I can't get to 1920x1440 as advertised on http://koolu.com/Koolu-WE-Appliance/Works-Everywhere-Appliance.html , but that may be my monitor's maximum resolution).
> 2) The VGA controller is not automatically detected and related to the geode driver, I had to do that manually through displayconfig-gtk.
> 3) When booting, the second half of the usplash process is still garbled (will post photo).
> 4) Minor: Also in between booting and getting to the desktop, it seems that the monitor flickers as if the refresh rate was not set properly.

Do you mean 2.8.0-7ubuntu2 as available in my PPA? This one
incorporates the libDDC patch that Brian at Koolu reports to be fixing
the issue.

Brian, does 2.8.0-7ubuntu2 work for you as well as your self-compiled binaries?

David, could you test one thing for me using a Koolu unit?

I need to compare whether auto-configuration performs correctly both under PXE boot (with e.g. Edubuntu's LTSP implementation) and under normal IDE boot from a locally installed Ubuntu distribution.

While I do not have access to an ION 603, on my ThinCan this works fine when booting from a local disk, but fails to auto-configure under LTSP.

PS: by contrast, 2.7.7.7 works equally well in LTSP and on a local disk, on this ThinCan.

With the help of Mart Raudsepp from Gentoo, we have backported the libDDC patch to AMD 2.7.7.7 and called the result 2.7.7.8-0ubuntu1.

This one gets correctly detected inside LTSP too.

Test packages are in my PPA. Just install them in the chroot (making sure to purge -amd and -geode first), then exit and run ltsp-update-image to test this.

My guess is that something in X server core prevents automatic detection, possibly a list of known drivers from which X won't deviate.

Here's the version of Jordan's patch that I used to make the above 2.7.7.8-0ubuntu1 package.

...and a revised version of the X core patch (from upstream git) that I used to add the AMD driver to the X server magic.

After further testing, it turns out that:

1) Whether I use -amd or -geode, they still need to be specified in xorg.conf for the driver to be found by X. Otherwise, X reverts to -vesa. I probably missed that earlier, simply because I've always used an xorg.conf on workstations, to make sure I would get the right default keyboard map and color depth (but leaving resolutions undefined).

2) Using -amd (the earlier 2.7.7.7-1 or the above 2.7.7.8-0ubuntu1 with the backported libDDC patch), hosts booting from an LTSP chroot correctly auto-configure. Using -geode, X simply fails to launch completely. Here, it's a bit more strange since I'm pretty sure that it worked a week ago, when -geode was initially imported into Hardy.

I'm curious as to whether others can reproduce the above behavior on other Geode LX -based products?

Martin-Éric, I'm trying to get the geode driver for testing on the Koolu and I am unable to find it. With your PPA being the only active one I am getting:

#apt-cache search geode
xserver-xorg-video-amd-dbg - X.org server -- AMD Geode GX/LX display driver (debugging symbols)
xserver-xorg-video-amd - X.org server -- AMD Geode GX/LX display driver
xserver-xorg-video-nsc - X.Org X server -- NSC display driver

What driver would you like to be test on the Koolu. I was under the impression that it was xserver-xorg-video-geode 2.8.0-7-ubuntu2.

On Mon, Apr 21, 2008 at 6:52 PM, David Bensimon wrote:
> Martin-Éric, I'm trying to get the geode driver for testing on the Koolu
> and I am unable to find it. With your PPA being the only active one I am
> getting:
>
> #apt-cache search geode
> xserver-xorg-video-amd-dbg - X.org server -- AMD Geode GX/LX display driver (debugging symbols)
> xserver-xorg-video-amd - X.org server -- AMD Geode GX/LX display driver
> xserver-xorg-video-nsc - X.Org X server -- NSC display driver
>
> What driver would you like to be test on the Koolu. I was under the
> impression that it was xserver-xorg-video-geode 2.8.0-7-ubuntu2.

Davif, amd 2.7.7.8-0ubuntu1 should do the trick as well as geode
2.8.0.-7ubuntu2. The main thing to verify is whether the libDDC patch
finally makes DDC offer more than 800x600 to a Koolu workstation, in
standalone operation with a hard-disk or over PXE using LTSP.

--
Martin-Éric Racine
http://q-funk.iki.fi

Further discussion with Oliver Grawert, Julien Cristau and Timo Aaltonen exposed the following situation:

1) the X server core in Hardy still doesn't know about manufacturer ID 0x1022 (Geode LX) and so it is unable to run without xorg.conf or with an xorg.conf that omits the Drivers line. Fixing this would require the above 171_xf86AutoConfig_geode_addition.diff patch, defining "geode" as the driver for chips manufactured by PCI manufacturer ID 0x1022.

2) "Xorg -configure" correctly finds the "geode" driver and produces an xorg.conf.new that contains the Driver line "geode". This should make it work in LTSP, but this currently fails for reasons unknown.

3) auto-detection of the correct driver as in [1] and production of xorg.conf using "Xorg -configure" as in [2] use two distinct methods for running X. The two methods are probably out of sync with regards to available X video drivers and how to use them.

The libDDC patch I previously used to produce 2.8.0-7ubuntu2, for comparison.

@Martin-Eric
>Do you mean 2.8.0-7ubuntu2 as available in my PPA?
Yes. Do you think you can find what is causing the monitor flicker at login that Jordan and I are encountering?

@Jordan
>Attach your X log
Done.

>Xorg -configure works
This did not work for me, since I edited xorg.conf directly.

Re: scrambled image
>That is kernel based breakage
Bug Number?

--

The following worked for me so I will post it as a current workarround:

Package Tested:
xserver-xorg-video-amd 2.7.7.8-0ubuntu1

Source:
deb http://ppa.launchpad.net/q-funk/ubuntu hardy main
deb-src http://ppa.launchpad.net/q-funk/ubuntu hardy main

Instructions:
1) Install Hardy
2) Add souces above to /etc/apt/sources.list
3) sudo apt-get install xserver-xorg-video-amd=2.7.7.8-0ubuntu1
4) Edit /etc/X11/xorg.conf by adding " Driver "amd" " to the Device Section
5) Reboot and the login screen is at maximum resolution

Now is there a possibility to automate detection so that the user won't have to modify xorg.conf?

Try fetching the test packages for a patched X server core from the same PPA and see if it helps.

I have tried reverting the xorg.conf to automatic configuration (i.e. "Configured Device") and tried running X -configure, Xorg-configure and the assistant in recovery mode for Fixing X issues. even with the updated X core (from the PPA) which you recommend, auto detection/assignment of the AMD driver is not made.

I can confirm that the xserver-xorg-video-amd 2.7.7.8-0ubuntu1 package in Martin's PPA provides the libDDC patch.

This requires (as mentioned by Martin) explicit declaration of the "amd" driver in Xorg.conf .

There's still something outstanding in the xserver-xorg-core as mentioned by David pertaining to autoconfiguration of the driver choice (it continues to default to VESA). I tested both the current version in the hardy repository (1.4.1~git20080131-1ubuntu9) and the one in Martin's PPA (1.4.1~git20080131-1ubuntu12) of xserver-xorg-core.

Confirmed resolution my current maximum is 1680x1050 (which is the max on my monitor). I don't have hardware which can match the specs of the VGA adapter (1920 x 1440). An improvement I noticed was that I do not see any flicker. This driver seems to work well. Let's get automatic detection into xserver-xorg-core and we can close this bug and submit the new packages to Ubuntu's main repositories.

I've tested on a linutop 2 box (similar hardware than the Koolu one), it also works for me ('amd' needs to b specified in xorg.conf). The screen detection worked perfectly for two screens (1280x1024 and 1680x1050).

So, we've at least verified with two vendors utilizing an ION 603 variant (with an Award BIOS) that the libDDC patch accomplishes what we intended: to bypass reliance on BIOS environment to get correct DDC information.

We've also verified that the same works and introduces no regression on unrelated hardware running another vendor's BIOS (General Software), this time a DBE61 (which also happens to be a Linutop-1).

Given this, would an immediate GEODE 2.8.1 release sound like a reasonable path to resolve at least part of this bug (detection of resolutions larger than 800x600 on an ION 603)? Jordan? Would there be any chance of getting such a 2.8.1 into Hardy as a bug fixing release? Steve?

This of course leaves open the issue of getting X to use GEODE on Geode-based hardware, rather than revert to VESA. This should be the title of a separate bug, entitled "X fails to detect Geode LX hardware and to use the GEODE driver on a host without xorg.conf".

...which I just reported as https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/220510

Martin-Éric Racine [2008-04-22 5:17 -0000]:
> Would there be any chance of getting such a 2.8.1 into Hardy as a
> bug fixing release? Steve?

Not into hardy final any more most likely, but those kind of hardware
enabling fixes are absolutely appropriate for hardy-updates, so that
they can become part of 8.04.1 (to be released in July).

Yes, what I meant was via proposed-updates, so that it would be apt-get'able from somewhere other than my PPA, before then.

I would rather not make this part of a 2.8.1 release, and I would like to stick to our existing roadmap of a 2.9.0 release on June 15. That will give us time to do the other work that we had planned. I have not been convinced that we are in a hurry here to make any distribution based deadlines, which is really the only reason why we make releases in the first place.

Unfortunately, getting a new major upstream release into Hardy won't be possible - unless it fixes a security issue - whereas getting a point release with only one small change for DDC implementation and an autoreconf stands much better chances of getting accepted.

Figuring out what produces the inconsistencies in how X 1.4 deals with "geode" between "Xorg -configure" (finds the right driver and prints a configuration that uses "geode"), X without xorg.conf (reverts to "vesa") and calling the driver as "amd" via a symbolic link (fails in Hardy LTSP) is also the sort of bugfixing that stands good chances of being acceptable for8.04.1 (Hardy point release one), but a new major upstream X with all the fixes already included would not be accepted.

geode_280_libddc.patch was applied to a pristine 2.8.0 tarball, then ./autogen.sh and "make distcheck" were ran. The result is 2.8.0+git20080424-1 which is currently sitting in Debian unstable. The Debian source package can be built against Hardy using pbuilder.

Please note that upstream would be willing to release a new tarball with just this libDDC patch and autoreconf, calling that 2.9.0.
Would this be acceptable as an SRU for 8.04.1?

The main advantage of upstream applying the patch and running autoreconf for us is that we'd keep the diff to a minimum, whereas running autoreconf ourselves would give us a pointlessly huge diff.

Comparing the 2.8.0+git20080424-1 sitting in Debian with the 2.8.0-7 we have in Ubuntu should give everyone a fair idea of how this would pan out.

Hi,

Martin-Éric Racine [2008-05-02 8:29 -0000]:
> Please note that upstream would be willing to release a new tarball
> with just this libDDC patch and autoreconf, calling that 2.9.0.
> Would this be acceptable as an SRU for 8.04.1?

Yes, it would be.

This was a treasure to stumble upon :)

After much investigation, I tried David Bensimon's workaround from 21/4 and finally managed to get my fit-PC (http://www.fit-pc.com/new/specifications.html) to show a resolution greater than 800x600 when running Hardy.
Unfortunately, I'm not able to test for greater than 1280x1024.

Thanks again.

2.9.0 has been released by upstream and is being uploaded into Debian as we speak. The upstream commit diff between 2.8.0 and 2.9.0 is attached as evidence for the SRU. The only other changes to the upstream tarball are the ChangeLog and files produced by autoreconf.

I'm nominating this as an SRU for Hardy:

1. The bug is a failure to perform DDC polling on hardware with broken BIOS environment. It affects a number of hardware products, including some OEM hardware sold by Ubuntu-certified Canonical partners.

2. Upstream addressed this issue by replacing code fragments that are dependent upon BIOS environments with new code that leverages X.org's own DDC polling library. This allows the driver to directly poll the DDC pins itself via libDDC and to parse the EDID information in a reliable and consistent way that is independent of BIOS features.

3. Find the attached xf86-video-geode_280_to_290.diff that shows the diff between 2.8.0 currently in Hardy and this new 2.9.0 released by upstream. The upstream commit diff between 2.8.0 and 2.9.0 is attached. The only other changes seen in the upstream tarball are the ChangeLog and autoreconf results, both of which are auto-generated at release time by tarball creation scripts. Upstream produced this release using Hardy versions of the libtool/autoconf/automake on a host running Hardy.

4. Reproducing the issue requires an OEM version of the FIC ION603, as sold by vendors such as Koolu, Linutop and Sumo Systems.

TEST CASE:

a) Launch X.org with an xorg.conf configured to utilize the "geode" driver.
b) Witness the driver falling back to its 800x600 lowest default resolution.

NOTE: the same issue is randomly reported on #ltsp as affecting other Geode -based products with a BIOS from other vendors as well.

5. We cannot think of any situation where this change would introduce any regression. If there's one thing, it should suddenly make this driver usable on a much wider variety of Geode -based hardware than before.

*****
This package needs to be sync'ed from Debian/unstable to hardy-proposed.

I've reviewed the patch; here's the changes it implements:
  * Version from 2.8.0 to 2.9.0
  * Adds file geode_ddc.c to implement routines for querying monitor capabilities via DDC
  * Switches code to use DDC querying routines
  * Drops old code that used VBE's EDID querying for monitor capabilities

All in all, the patch looks sane to me, and although I've not tested it myself, it looks acceptable to me.

Looks like 2.9.0-1 is now in Intrepid - setting to fix released.

Thanks for getting this into Intrepid!

What are we missing to get this as an SRU into Hardy?

Thanks for the review, Bryce. Ack from SRU team.

Was uploaded to hardy-proposed yesterday by Ogra. Is there anything else left to do to get this in?

Accepted into -proposed, please test and give feedback here

Hardy-proposed now has both a newer X server core and GEODE driver available:

deb http://ee.archive.ubuntu.com/ubuntu/ hardy-proposed main universe restricted #multiverse
deb-src http://ee.archive.ubuntu.com/ubuntu/ hardy-proposed main universe restricted #multiverse

Please test and report your findings ASAP. If no major issue is reported within the next couple of weeks, this will be pushed into Hardy as an update.

PS: Intrepid already has both fixes uploaded since a few days too.

Please try packages in my PPA for GEODE 2.9.0-1ubuntu2 which add support for Debian/Ubuntu-specific X server files and test whether this fixes the issues.

This package adds support for the Debian/Ubuntu-specific way of defining supported PCI ID numbers for each driver. The additions I made add support for:

* Vendor: NSC, Chip: GX.
* Vendor: AMD, Chip: LX.

Fixed package uploaded to hardy-proposed, please test this and give feedback here:

 xserver-xorg-video-geode (2.9.0-1ubuntu2) hardy-proposed; urgency=low
 .
   * Added usr/share/xserver-xorg/pci/geode.ids. (LP: #131675)

2.9.0-1ubuntu2 was just replaced by 2.9.0-1ubuntu3 to completely close this issue. It's already available in my PPA and should soon be uploaded to Hardy-proposed. For Intrepid, package 2.9.0-3 (pending import from Debian/unstable) includes the same fixes.

New version accepted into hardy-proposed.

2.9.0-1ubuntu3 doesn't fix it for me, and neither does the earlier amd (2.7.7.8-0ubuntu1) from Martin-Éric's PPA. Actually, I get the same result regardless of the driver I specify in lts.conf with this geode client.

I should specify that the new version does fix the problem of resolution (vesa fallback) for me if I start the client from its own disk. The problem that persists is that I get a blinking cursor on a black screen instead of X when I start up a geode machine (lx800) as an ltsp client, regardless of what driver I specify in lts.conf.

I added hardy-proposed to my sources.list, ran an update and installed the following three packages.

xserver-xorg-core
2:1.4.1~git20080131-1ubuntu9 -> 2:1.4.1~git20080131-1ubuntu9.1

xserver-xorg-video-geode
2.8.0-7 -> 2.9.0-1ubuntu2.1

xserver-xorg-video-ati
1:6.8.0-1 -> NO CHANGE

The resolution boots into 1280x1024 (max) now instead of 800x600.

To retrace my steps and verify that this indeed solves the Geode issues, some people might find either of the two following methods suitable:

http://q-funk.blogspot.com/2008/06/howto-make-geode-thin-clients-work-on.html

http://q-funk.blogspot.com/2008/06/howto-build-clean-ltsp-boot-image-that.html

FYI, I have a Geode GX based machine (Dectop) and using the latest xserver-xorg-video-geode driver from hardy-proposed (2.9.0-1ubuntu2.3) I get pretty much the same result as I did just by specifying Driver "amd" in xorg.conf before installing it. I get garbled video. Figured I'd mention it since I am not sure if anybody has been testing this for the GX.

Martin-Éric Racine wrote:

> http://q-funk.blogspot.com/2008/06/howto-build-clean-ltsp-boot-image-
> that.html

Following this, solved my issue's. I can use the Linutop now with my
ltsp server.

Hi, this is a question non-related with the bug, i've the same thin client (FIC ION A603) and It comes with a linux distribution but I want to install Ubuntu and I don't know the boot's key, thanks.

PS: I was trying to contact you by e-mail but I couldn't find it, thanks.

Hi Francisco,

To get into the BIOS press "DEL" at boot.
To get into the Boot Menu press "Shift+F10" at boot.

AFAIK the fix is already released for Hardy as well.

This was copied to hardy-updates a while ago.

Hey guys, I have been working around this Koolu unit since I have bought one for the bedtime!
I just can't get the video to work properly. I have tried so many things but all seems not to end up good.
I am running 8.04 Mythbuntu. I can't reach more that 1024 resolution. Moreover, I can barely watch a recording from my server since the video lacks so much it is barely watchable. I am not bad with linux but far from an expert. I know how to run most of the commands but I am confused about the driver I should use and the way to get it to work in my thin client. Can you help me with that?

I am asking you guys since there is not allot of people who know that kind of can!
Thanks in advance
Stephane

xorg.conf