openchrome drivers

[nicolas314]

I have upgraded my MicroClient Senior to Ubuntu Hardy Heron, and I
must report the openchrome driver is still not ready for prime time on
that platform. I have a large screen supporting many different
resolutions and none is correctly handled except 1280x1024. mplayer
plays jerky videos, vlc has trouble reading videos at all.

I tried installing the latest Ubuntu snapshots from openchrome.org but
results are pretty much the same.

Add to that: the new X.org version in Ubuntu Hardy finally has auto-
detection features for all hardware, which is nice when it works but a
real pain when it does not since there are no config files you can
edit to correct the situation. For some reason I have no access to the
standard Linux consoles (CTRL-ALT-F1 just does not respond), though it
may just be that they changed the convention for calling the consoles.
It does not help too much when you are trying to solve X.org-related
issues. Will check it out on Ubuntu forums to see if anybody got
better support.

Seems like using MicroClient Senior for desktop is more trouble than I
initially thought. gOS seemed to work better on the same hardware
though I do not really understand why it would, being Ubuntu-based.

I may just revert back to a Debian-based pure network machine with
this box and wait until hardware support under Linux is up to the task.

[Olivier]

Hi nicolas,

I don't use a X server on my microclient, so I can't answer you
precisely.
What can I say is :
- tty console are started by upstart see, configuration file in /etc/
event.d/tty*
- you can verify that they are running (ps -ef | grep getty)
- AFAIK the combination of keys ctrl+alt+fn are handled directly by
the kernel. It sounds like a buggy driver. I remember that in old
version of nvidia driver, switching to virtual console was not
possible if an option (something like "sync to vertical/horizontal
blank" ...) was set.

Keep us informed on your progress... (if one day I decide to use a
screen with my microclient... :) )
Olivier.

[nicolas314]

Strike what I said earlier. I just upgraded Hardy to the latest
version and everything is working fine now! Graphics are perfectly
smooth, videos play full-screen very nicely and sound is not even
interrupted. Ubuntu Hardy is definitely getting better every day :-)

--
Nicolas

[Lolo Buell]

So with the last Ubuntu version, we don't need openchrome driver anymore ?

2008/4/23 nicolas314 <nicol...@gmail.com>:

[nicolas314]

Ubuntu Hardy comes with openchrome drivers that fully support the
MicroClient chip.
At least that is what I observe now!

--
Nicolas

[graham....@gmail.com]

This is good news. I plan on installing Hardy Heron on my main
computer this weekend, maybe i'll also upgrade the MicroClient...
Although, is Hardy Heron Xubuntu available yet?

Graham

[nicolas314]

Yes, Xubuntu (and Kubuntu) 8.04 have been released the same day too.
Just search and replace gutsy/hardy in your sources.list and dist-
upgrade.
The result is beautiful and running incredibly smooth.
Watching movies fullscreen on a 1680x1050 screen using a completely
silent box is kind of surprising. We are living in the future, guys!

--
Nicolas

[TimW]

What are you using to view your movies? I've just installed Ubuntu,
and out of the box, using Totem, the picture is distorted, discoloured
and has far too many frame drops to be watchable. I've had fullscreen
video working in PCLinuxOS but not yet in Ubuntu. Did you install
anything extra to get that performance?

[z0ltan]

Hi,
I was using my microclient with xubuntu gutsy and openchrome drivers
compiled with last trunk, and it was working fine (using vlc and
xvideo output module), but since i upgraded it to hardy (dist-
upgrade), videos are running weird... there is a pink line on the top
of the screen and a strange rubber on the left... I tried to re-
compile openchrome drivers from latest sources, but the problem still
appears.
Any idea ?

[nicolas314]

I am far away from my MicroClient right now, but I will post whatever
information I have about my current configuration. As far as I
remember, I just dist-upgraded from Gutsy to Hardy and got everything
working fine with either mplayer or vlc. Might be a screen-related
issue?

--
Nicolas

[TimW]

Im sure the problem lies with xvmc. Nicolas, can you do the following
two commands so that we can compare the output, please?

tim@ubuntu-microclient:~$ cat /etc/X11/XvMCConfig
libXvMC.so.1
tim@ubuntu-microclient:~$ ls -l /usr/lib/lib*XvMC*
-rw-r--r-- 1 root root 842 2008-01-23 11:46 /usr/lib/
libchromeXvMC.la
-rw-r--r-- 1 root root 860 2008-01-23 11:46 /usr/lib/
libchromeXvMCPro.la
lrwxrwxrwx 1 root root 25 2008-05-03 22:28 /usr/lib/
libchromeXvMCPro.so -> libchromeXvMCPro.so.1.0.0
lrwxrwxrwx 1 root root 25 2008-05-03 22:28 /usr/lib/
libchromeXvMCPro.so.1 -> libchromeXvMCPro.so.1.0.0
-rw-r--r-- 1 root root 45136 2008-01-23 11:46 /usr/lib/
libchromeXvMCPro.so.1.0.0
lrwxrwxrwx 1 root root 22 2008-05-03 22:28 /usr/lib/
libchromeXvMC.so -> libchromeXvMC.so.1.0.0
lrwxrwxrwx 1 root root 22 2008-05-03 22:28 /usr/lib/
libchromeXvMC.so.1 -> libchromeXvMC.so.1.0.0
-rw-r--r-- 1 root root 42956 2008-01-23 11:46 /usr/lib/
libchromeXvMC.so.1.0.0
lrwxrwxrwx 1 root root 20 2008-04-29 03:33 /usr/lib/libI810XvMC.so -
> libI810XvMC.so.1.0.0
lrwxrwxrwx 1 root root 20 2008-04-29 03:33 /usr/lib/libI810XvMC.so.
1 -> libI810XvMC.so.1.0.0
-rw-r--r-- 1 root root 44352 2008-04-10 10:18 /usr/lib/libI810XvMC.so.
1.0.0
lrwxrwxrwx 1 root root 22 2008-04-29 03:36 /usr/lib/
libviaXvMCPro.so -> libviaXvMCPro.so.1.0.0
lrwxrwxrwx 1 root root 22 2008-04-29 03:36 /usr/lib/
libviaXvMCPro.so.1 -> libviaXvMCPro.so.1.0.0
-rw-r--r-- 1 root root 44460 2007-11-02 02:37 /usr/lib/
libviaXvMCPro.so.1.0.0
lrwxrwxrwx 1 root root 19 2008-04-29 03:36 /usr/lib/libviaXvMC.so -
> libviaXvMC.so.1.0.0
lrwxrwxrwx 1 root root 19 2008-04-29 03:36 /usr/lib/libviaXvMC.so.1
-> libviaXvMC.so.1.0.0
-rw-r--r-- 1 root root 41768 2007-11-02 02:37 /usr/lib/libviaXvMC.so.
1.0.0
lrwxrwxrwx 1 root root 16 2008-04-29 05:21 /usr/lib/libXvMC.so.1 ->
libXvMC.so.1.0.0
-rw-r--r-- 1 root root 10076 2007-07-24 10:59 /usr/lib/libXvMC.so.
1.0.0
lrwxrwxrwx 1 root root 17 2008-04-29 05:21 /usr/lib/libXvMCW.so.1 -
> libXvMCW.so.1.0.0
-rw-r--r-- 1 root root 14796 2007-07-24 10:59 /usr/lib/libXvMCW.so.
1.0.0

TIA

[nicolas314]

> tim@ubuntu-microclient:~$ cat /etc/X11/XvMCConfig
> libXvMC.so.1

Ok

Following links and files are correct:

/usr/lib/libchromeXvMC.la
/usr/lib/libchromeXvMCPro.la
/usr/lib/libchromeXvMCPro.so
/usr/lib/libchromeXvMCPro.so.1
/usr/lib/libchromeXvMCPro.so.1.0.0
/usr/lib/libchromeXvMC.so
/usr/lib/libchromeXvMC.so.1
/usr/lib/libchromeXvMC.so.1.0.0
/usr/lib/libI810XvMC.so
/usr/lib/libI810XvMC.so.1
/usr/lib/libI810XvMC.so.1.0.0

/usr/lib/libXvMC.so.1
/usr/lib/libXvMC.so.1.0.0
/usr/lib/libXvMCW.so.1
/usr/lib/libXvMCW.so.1.0.0


However I do not have these libs:

/usr/lib/libviaXvMCPro.so -> libviaXvMCPro.so.1.0.0
/usr/lib/libviaXvMCPro.so.1 -> libviaXvMCPro.so.1.0.0
/usr/lib/libviaXvMCPro.so.1.0.0
/usr/lib/libviaXvMC.so -> libviaXvMC.so.1.0.0
/usr/lib/libviaXvMC.so.1 -> libviaXvMC.so.1.0.0
/usr/lib/libviaXvMC.so.1.0.0

Where did you get these from?
Try: dlocate /usr/lib/libvia

Something else that just came to my mind: did you guys leave the CPU
in economy mode or activate it in 'normal' mode? You find the switch
in the BIOS. Default is economy, which means half CPU speed. That
would explain it.

--
Nicolas

[TimW]

> Something else that just came to my mind: did you guys leave the CPU
> in economy mode or activate it in 'normal' mode? You find the switch
> in the BIOS. Default is economy, which means half CPU speed. That
> would explain it.

I tried both ways, plus I could get full screen video in PCLinuxOS
without changing any BIOS settings so I doubt that is it.

I have found from /var/log/Xorg.0.log that XvMC isn't supported for
the CX700 in the version of the openchrome drivers included in Hardy
(which seems to correctly reflect the official status of the
openchrome drivers). I haven't checked what is going on in PCLinuxOS,
yet. I'll post again if I can get it working again.

[nicolas314]

> I have found from /var/log/Xorg.0.log that XvMC isn't supported for
> the CX700 in the version of the openchrome drivers included in Hardy

Here is what I get here in Xorg.0.log:

X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server
2:1.4.1~git20080131-1ubuntu9)
Current Operating System: Linux senior 2.6.24-16-generic #1 SMP Thu
Apr 10 13:23
:42 UTC 2008 i686
Build Date: 15 April 2008 05:26:17PM

[...]

(II) LoadModule: "openchrome"
(II) Loading /usr/lib/xorg/modules/drivers//openchrome_drv.so
(II) Module via: vendor="X.Org Foundation"
compiled for 1.4.0.90, module version = 0.2.901
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 2.0

(II) OPENCHROME: Driver for VIA Chrome chipsets: CLE266, KM400/KN400,
K8M800/K8N800, PM800/PM880/CN400, P4M800Pro/VN800/CN700,
K8M890/K8N890, P4M900/VN896/CN896, CX700/VX700, P4M890
(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device
(--) Chipset CX700/VX700 found
(!!) VIA Technologies does not support or endorse this driver in any
way.
(!!) For support, refer to http://www.openchrome.org/.
(!!) (development build, compiled on Wed Jan 23 11:46:14 2008)

[...]

(II) Setting vga for screen 0.
(II) CHROME(0): VIAPreInit
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 1.4.0.90, module version = 0.1.0
ABI class: X.Org Video Driver, version 2.0
(II) CHROME(0): VIAGetRec
(II) CHROME(0): Creating default Display subsection in Screen section
"Default Screen" for depth/fbbpp 24/32
(==) CHROME(0): Depth 24, (==) framebuffer bpp 32
(==) CHROME(0): RGB weight 888
(==) CHROME(0): Default visual is TrueColor
(--) CHROME(0): Chipset: "CX700/VX700"
(--) CHROME(0): Chipset revision: 0
(--) CHROME(0): Probed amount of VideoRAM = 65536 kB
(II) CHROME(0): Setting up default chipset options...
(II) CHROME(0): VIASetupDefaultOptions
(II) CHROME(0): Starting to parse config file options...
(==) CHROME(0): ShadowFB is disabled.
(==) CHROME(0): Acceleration is enabled.
(==) CHROME(0): Using XAA acceleration architecture.
(==) CHROME(0): Hardware two-color cursors; software full-color
cursors.
(==) CHROME(0): GPU virtual command queue will be enabled.
(==) CHROME(0): DRI IRQ will be enabled if DRI is enabled.
(==) CHROME(0): AGP DMA will be enabled if DRI is enabled.
(==) CHROME(0): AGP DMA will be used for 2D acceleration.
(==) CHROME(0): PCI DMA will be used for XV image transfer if DRI is
enabled.
(==) CHROME(0): Will not enable VBE modes.
(==) CHROME(0): VBE VGA register save & restore will not be used
if VBE modes are enabled.
(==) CHROME(0): Xv Bandwidth check is enabled.
(==) CHROME(0): Will not impose a limit on video RAM reserved for DRI.
(==) CHROME(0): Will try to allocate 32768 kB of AGP memory.
(==) CHROME(0): Digital output bus width is 12 bits.
(==) CHROME(0): DVI Center is disabled.
(==) CHROME(0): Panel size is not selected from config file.
(==) CHROME(0): Panel will not be forced.
(==) CHROME(0): TV dotCrawl is disabled.
(==) CHROME(0): TV deflicker is set to 0.
(==) CHROME(0): No default TV type is set.
(==) CHROME(0): No default TV output signal type is set.
(II) CHROME(0): VIAMapMMIO
(--) CHROME(0): mapping MMIO @ 0xfd000000 with size 0x9000
(--) CHROME(0): mapping BitBlt MMIO @ 0xfd200000 with size 0x20000
(II) CHROME(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset
is 0x0000
(==) CHROME(0): Will not print VGA registers.
(==) CHROME(0): Will not scan I2C buses.
(II) CHROME(0): ...Finished parsing config file options.
(--) CHROME(0): Detected VIA VT8454B.
(II) CHROME(0): Detected MemClk 6
(II) CHROME(0): ViaGetMemoryBandwidth
(II) CHROME(0): Detected TV standard: NTSC.
(==) CHROME(0): Using gamma correction (1.0, 1.0, 1.0)

This goes on and on for pages. Longest section is about my monitor:
detection through EDID, modeline computation and the like until it
settles for the native monitor resolution.

About installed packages:

ii libchromexvmc1 1:0.2.901-0ubuntu4
ii libchromexvmcpro1 1:0.2.901-0ubuntu4
ii xserver-xorg-video-openchrome 1:0.2.901-0ubuntu4

They seem to be the latest Hardy packages.

Since we have the same hardware and OS, I see no obvious reason why we
do not get the same results. You may want to try with another monitor
maybe?

--
Nicolas

[TimW]

I checked my xorg log on PCLinuxOS and it turns out that XvMC isn't
enabled on there, either. It looks like it is possible to get
fullscreen video without any acceleration of the decoding - imagine
what we'll get when openchrome does support it 8^).

I don't think it is my monitor, because I get fullscreen video on
there using PCLinuxOS and I've tried about 5 different monitors (I
made sure that my kids TVs had VGA ports, and I've taken the MC to
work to show to the guys there).

IIRC, the bit about XvMC in the log comes after all the monitor stuff.

I did notice in the PCLinuxOS log something about v4l which I don't
recall seeing in the Hardy log. I'll check that later. If it isn't in
there, I have no idea how to force it to load since the xorg config
file doesn't seem to really get used in Hardy.

I'll post again later with the results of the v4l check...

[TimW]

I was right. There is no v4l. I don't know much about v4l other than
the v stands for video and the l stands for linux. Is it used for
displaying video, or just for driving TVOUT ports? I saw a reference
to v4l2 being in the kernel but that it doesn't support all drivers
yet - maybe we have fallen down the hole but you still have v4l
installed because you upgraded rather than installing fresh? Or did
you re-install in the end?

This is just guess work now, because I don't really know anything
about v4l and the website isn't responding ATM.

[nicolas314]

v4l is a (hopefully) generic interface to video acquisition devices like
framegrabbers, webcams, or video cameras. It does not handle video
output.

About my Hardy install: if I had to write a HOWTO, it would go like:

- Screw the hard drive into a USB enclosure. Plug it into your desktop
- Start up qemu, boot on the Gutsy ISO image and install to the USB disk
- Wait 4 hours because you forgot to load kqemu, thinking that such an
install should not take too long
- Wait a couple more hours, just to see how far your nerves can hold
- When the install bar reaches about 98%, hit ALT-F4 to change to
console #4 in the virtual machine, only to realize that qemu had not
grabbed the focus and ALT-F4 in your window manager means "kill the
focused window", i.e. qemu. Install screwed at 98%.
- Go have a drink. Check your watch: it is 2am, the kids have school tomorrow.
- Take the hard drive out, plug it into the MicroClient
- Correct grub install issues like hard drive names and UUIDs
- Finally boot the MicroClient with the new hard drive running a 98%-Feisty
- Some parts of the OS are missing but the OS boots correctly. How do you
repair a live system? Search/Replace gutsy/hardy in /etc/apt/sources.list
then do an update/dist-upgrade and go to bed.
- Next day keep saying "Yes" to all questions until the install is finished.

At that point I believe I had a working Hardy installation. The video drivers
were not working but remember this all happened a couple of days before
Hardy was officially released. The video driver has been working fine
since then. I have been experimenting with the latest drivers from the
openchrome web site and did not get better results.

Will dig into config files and libraries to see if I modified something else
during my unusual install.

--
Nicolas <nicol...@gmail.com>

[TimW]

I went back to an old, slow CF card I had which I had installed gOS
on. gOS is (was?) based on 7.10, at least at the time when I did that
install, and sure enough fullscreen video was working (just about -
certainly much better than under Hardy). After your upgrade to Hardy,
did your xorg.conf look like the old-style one which had all the
configuration in, or the new-style one which just says that X should
use the "configured" screen etc. with no hint of where it is
configured? I'm away from my MC right now, but I'm thinking of copying
across my 7.10 xorg.conf to my Hardy install.

[nicolas314]

I had gOS installed on a CF too, but could not play fullscreen videos with it. The whole thing was rather slow and it was obvious the video driver was to blame. Investigations showed that it was running in VESA mode. After switching to Hardy, my xorg.conf looks empty with nothing specific indicated, only generic comments about using the default screen, default card, etc. As I mentioned in my first post: when it works it is great but when it does not you do not know where to start.

One thing I noticed: if I boot the MicroClient with no monitor attached, it switches to VESA compatibility mode in low-resolution. I can see it when I later connect a monitor. If I then restart X with ctrl-alt-backspace, it performs an auto-detect of the monitor and switches to the monitor native resolution (1680x1050), using the openchrome driver instead of vesa. Playing movies with mplayer fullscreen at 1680x1050 works fine. The CPU is stuck at 99% but I experience rare framedrops and sound is perfect. I expect things to improve when the openchrome drivers are programmed to use the MPEG decoding chip embedded in the MicroClient.

BTW: somebody pointed out to me that to avoid answering 'yes' to a thousand questions when doing dist-upgrade, you can use the -y or --assume-yes switch for apt-get.

--
Nicolas

[TimW]

> I had gOS installed on a CF too, but could not play fullscreen videos with
> it. The whole thing was rather slow and it was obvious the video driver was
> to blame. Investigations showed that it was running in VESA mode. After

Yes, I manually installed the openchrome drivers to get to where I am
at with it. I think I'll try uninstalling and then re-installing the
openchrome drivers on my Hardy card. I'm not 100% certain it is the
drivers now, though. I'm starting to suspect the video codecs.

> BTW: somebody pointed out to me that to avoid answering 'yes' to a thousand
> questions when doing dist-upgrade, you can use the -y or --assume-yes switch
> for apt-get.

That'll be my next plan 8^). It took hours to get to where I'm at
right now so I don't want to restart if I don't have to 8^).

[TimW]

Fixed it! It turns out that it was the codecs, not the video driver.
What I had to do in the end was to use the package manager to remove
all the gstreamer...bad packages, and then make sure all the codecs
etc come from medibuntu. I may re-install from scratch making sure
that I have medibuntu in the repository lists before doing anything.

Nicolas, many, many thanks for all your help. Without your input I
would have assumed it was going to be impossible long ago, plus you
helped me avoid spending too long on some of the dead ends I was
exploring.

[nicolas314]

Good job!
Just for posterity, you might want to post your codec package versions
for others who may fall into the same pit.

Credit is yours, mate. I only pointed out that it worked on my box!
--
Nicolas

[TimW]

> Just for posterity, you might want to post your codec package versions
> for others who may fall into the same pit.

To tell you the truth, as always happens in cases like this, I'm not
sure exactly what the fix was, and a *lot* of packages got installed
when I used Medibuntu. I'd summarise the situation by advising "Don't
play any media until after you have added Medibuntu to your
repositories and done an upgrade". I think I got into the situation by
trying to play something relatively soon after my Hardy install, and
accepting whatever codec it suggested. It turns out that it came from
one of the gstreamer packages which are actually marked as "bad".

To get out of the situation once you are in it, search for all
packages with "gstreamer" in the name. One of them will probably have
"bad" as part of it's title. Remove that, add Medibuntu to your
repositories and do an upgrade.

You *may* not have to remove any packages so don't worry if you can't
find a bad gstreamer package. I did that, but it may be that the
medibuntu repository dependencies are clever enough to sort it all out
for you any way.

Instructions for adding the Medibuntu repositories are here:
https://help.ubuntu.com/community/Medibuntu#head-7486ed038a9becc1dff10a24cc07a38a00d70e9f
(I believe that link will work - it looks a lot like a session token
but I did check it - if it fails, just search for Medibuntu in google
- the repositories aren't hard to find once you've found the project
pages).

[TimW]

A bit more info on what does and doesn't work:

Totem does *not* work...the picture "tears" and the infamous green bar
appears. I haven't found any way of fixing this yet.

xine works but runs out of CPU power if used in anything (that I have
tried) other than xfce (the xubuntu desktop). Even gnome is enough to
start frame dropping.

mplayer doesn't work (too many framedrops), but can be made to work if
you force the video output to be xv and the audio output to be alsa
(you can do this either on the command line, or in gmplayer's
preferences). It seems to use less CPU than xine, but I haven't tried
it enough to be sure yet.

vlc doesn't work but is probably like mplayer - defaulting to the
wrong output drivers. I haven't yet tried forcing it to use the (more)
correct ones.

[efge]

Mplayer runs smoothly fullscreen using 35% CPU power.

I run Puppy 3.01 with the proper openchrome drivers - compiled on my
Microclient -
and the special version of Mplayer compiled for unichrome support.

I can so testify it is possible to use the real capacities of the
video component of the MC.

[nicolas314]

Here is what I get here with an MPEG-4 movie:

- Totem works. I do observe some framedropping in the beginning while
it is loading data, but once the buffer is full it runs fullscreen
without any noticeable error. No tears or green bar here.
- mplayer works great. Fullscreen without framedrops. Forget about
using Firefox simultaneously though.
- vlc is slow to startup, complains about having to drop the first 5
seconds and then goes wild. It seems I get very different results with
different codecs though.

I did not install xine, nor did I have to specify some kind of
preferred output.

Ah yes, one thing to mention: I had to reinstall Ubuntu (Hardy) from
scratch recently on the MicroClient Senior. I was a little bit erm...
clumsy. Good thing is: I can now say I have a vanilla Ubuntu Hardy
install ;-)

efge: you mention installing the latest openchrome drivers and
openchrome-patched mplayer. Pointers welcome!

--
Nicolas

[nicolas314]

About getting MPEG hardware acceleration to work on the MicroClient
Senior:

I have been hunting around for the "proper openchrome drivers" without
results so far. From what I gathered there are two open-source
projects based on the same initial fork to support Via's chips:
unichrome and openchrome.

Openchrome' s latest version is 0.2.902 and Hardy is distributed with
0.2.901. Both versions claim no support for Xvmc on CX700. I can
confirm this by looking into /var/log/Xorg.0.log:
(WW) CHROME(0): [XvMC] Not supported on this chipset.
This is also confirmed by checking the README file for this project.

Unichrome seems to claim support for CX700 but Ubuntu Hardy refuses to
install the package xserver-xorg-video-unichrome, mentioning some
weird conflict issues. Diving into the source code for the latest
Unichrome drivers is not especially helpful. You find some mentions of
CX700 but it is not clear whether Xvmc is supported or not with this
driver. If you have any success using it, may I ask you which version
you use?

About mplayer itself I found the following page:
http://wiki.openchrome.org/tikiwiki/tiki-index.php?page=XvMC#Mplayer
Unfortunately it seems that Xvmc needs to be supported by the X driver
in order for mplayer to use it so we are back to the previous issue.

Any help appreciated

--
Nicolas

[efge]

Sorry Nicolas, my post was a bit short.
The problem is i have worked on puppy; it was rather boring to compile
the drivers,
libdrm and all the stuff necessary to activate direct rendering....but
i manage to
compile the latest openchrome drivers 0.2.902 with the 2.6.21.7 kernel
headers
used on Puppy 3.01.

I have detailed the dri activation process on the microclient.fr wiki
[category: drivers]

My pet package is here:
http://s146374890.onlinehome.fr/puppy/openchromeviak2.6.21.7-0.2.902.pet
[tgz format, you can process it as usual]

It would be difficult to tell you how i finally managed to compile
this. It is an horrible
bunch of tricks -at least on Puppy- because of library version
conflicts, missing
sources...a real nightmare. I almost gave it up.

Imho, it would be much easier to compile them on uBuntu.
You need the openchrome sources, the xorg devel sources,
the kernel headers...the libdrm sources...and some patience :)

For Mplayer i used the special version tempestuous compiled with
support for VIA unichrome graphics chips:
http://www.murga-linux.com/puppy/viewtopic.php?t=26511

This version use the XvMC lib "libviaXvMCPro.so.1" [the XvMC libs are
included in my pet]
which fully benefits from the cn700 chip.

I dont know if this could help on uBuntu.
I would really like to have more time to investigate on uBuntu, but i
choose to
work on Puppy, which is to me the best os for the Microclient.

Dont hesitate to contact me - it will be easier in french ;)