Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 54079 - Add unichrome.sf.net driver
Summary: Add unichrome.sf.net driver
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Default Assignee for New Packages
URL:
Whiteboard:
Keywords:
: 94807 96123 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-06-16 05:32 UTC by Herbie Hopkins (RETIRED)
Modified: 2011-08-25 17:43 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
xorg-x11-6.7.0-r1.ebuid patch to provide unichrome drivers (xorg-x11-6.7.0-r1-unichrome.patch,1.21 KB, patch)
2004-06-16 05:33 UTC, Herbie Hopkins (RETIRED)
Details | Diff
xf86-video-unichrome-0.2.6.ebuild (xf86-video-unichrome-0.2.6.ebuild,876 bytes, text/plain)
2006-12-17 07:59 UTC, Chris Mayo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Herbie Hopkins (RETIRED) gentoo-dev 2004-06-16 05:32:44 UTC
Attached is a patch to x11-base/xorg-x11-6.7.0-r1 to provide the unichrome drivers (http://unichrome.sourceforge.net/) for the VIA/S3G unichrome graphics core. These drivers enable XvMC support and allow you to use the chips builtin hardware mpeg2 decoder (in apps such as mythtv for example)

I've implemented this using a new USE variable, unichrome. With USE="-unichrome" (which should be the default) nothing has changed but with USE="unichrome" the via unichrome driver replaces the standard via driver and the libviaXvMC patch is applied.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1 Herbie Hopkins (RETIRED) gentoo-dev 2004-06-16 05:33:54 UTC
Created attachment 33370 [details, diff]
xorg-x11-6.7.0-r1.ebuid patch to provide unichrome drivers
Comment 2 Brian Jackson (RETIRED) gentoo-dev 2004-06-17 20:03:05 UTC
I gave this a spin on my via epia. Took forever to compile :( I fired it up, and it says something about needing dri to use xvmc. Maybe you could whip something up for dri support?
Comment 3 Herbie Hopkins (RETIRED) gentoo-dev 2004-06-18 01:55:14 UTC
dri should work as is, it does require a kernel drm module though. These drivers do not provide a user space dri library which is required for hardware accelerated opengl. I have dropped in the via binary via_dri.so (available from viaarena.com)  and then hardware opengl seems to work just fine. I am a little reluctant to add that to the ebuild though due to it's binary nature, although I guess it could go into a separate ebuild...

XvMC should work just fine without this though, at least it does here. Do you have the necessary kernel level support and/or do you have load "dri" in your modules section of xorg.conf?
Comment 4 Herbie Hopkins (RETIRED) gentoo-dev 2004-06-18 03:42:17 UTC
as for the kernel module, via drm is not in the current stock kernel release but can be obtained from dri.sf.net. Moreover hardware mpeg decoding on the cle266 requires a v4l module (the libddmpeg ebuild contains a comment on this). Maybe adding a epia-sources ebuild would be the best way of providing this kernel support (this could also include epia framebuffer driver etc). What do you think? comments welcome.
Comment 5 Brian Jackson (RETIRED) gentoo-dev 2004-06-18 11:12:08 UTC
I read a page of the dri wiki that said via support was not there yet. Maybe
it's a little outdated. I'll see what I can find out. There was an error
message that specifically said there would be no xvmc support without dri, but
I'll go back and verify if it's working or not. Yes I do have drm drivers in the kernel for the cle266.

As far as epia-sources is concerned. It's been suggested numerous times. I
don't think 3 features for a fairly small part of the market is really worth
it. Many people have been asked to provide patches to integrate those bits into
gentoo-sources, but I haven't heard of anyone actually doing it.
Comment 6 Herbie Hopkins (RETIRED) gentoo-dev 2004-06-21 02:19:01 UTC
I too am using these drivers with a epia-M board. Maybe I wasn't too clear before, I do have working dri and xvmc support purely with what's provided in this ebuild (plus kernel support). As to why it's not working for you I'm not too sure, does you log report why dri failed to initialise?

As for kernel support, I have created a patch that applies cleanly to gentoo-dev-sources-2.6.7 and includes via drm and via_v4l_drv modules. I think maybe a better approach would be to write an ebuild that compiles these modules outside of the kernel tree so I'll have a look at doing that if possible.
Comment 7 Donnie Berkholz (RETIRED) gentoo-dev 2004-06-21 02:29:39 UTC
I'm still watching to see how things develop upstream, so it might be a little bit before this stuff happens. I'd prefer to backport something committed to xorg than add in external things, if possible.
Comment 8 Donnie Berkholz (RETIRED) gentoo-dev 2004-07-07 02:19:34 UTC
The stuff has been merged into xorg CVS and will be in the next release. Just have a little patience and wait for it.

In the meantime, this bug can serve as a reference for anyone else who can't wait a little. =)
Comment 9 mark lybarger 2004-09-14 18:18:52 UTC
this ebuild doesn't apply cleanly to the xorg-x11-6.7.0-r1.ebuild that's in portage.  i had to manually apply the changes and am emerging it now.  we'll see if i can figure out how to configure this.  

i'm in the "don't want to wait" boat as i've had this laptop for maybe 6 months now and would really really like some hardware accelleration of some sort.  i take it i need more than this to get dri/drm.  that'll be the next step i suppose.  
Comment 10 Donnie Berkholz (RETIRED) gentoo-dev 2004-09-14 19:39:21 UTC
So use 6.8.0, and you'll probably need the USE=insecure-drivers to get the via acceleration stuff. Also grab x11-drm with VIDEO_CARDS=via.
Comment 11 Herbie Hopkins (RETIRED) gentoo-dev 2004-09-15 01:05:09 UTC
The unichrome drivers have not been merged into xorg cvs yet so you won't get acceleration with 6.8 either for that chipset. They keep threatening to but it has not happened yet. For more info see the unichrome maining list:
http://sourceforge.net/mailarchive/forum.php?thread_id=5533761&forum_id=38837
maybe we'll see them in the next release...
Comment 12 Donnie Berkholz (RETIRED) gentoo-dev 2004-09-15 10:49:03 UTC
Please test it. According to the commit messages, at least some of it's there:

- Change the VIA DDX to tell clients to look for unichrome_dri.so, the
  module that X.Org distributes.
- Move the VIA DRI into DevelDRIDrivers because it is still insecure.
  See: http://dri.sourceforge.net/IRC-logs/20040628.txt

http://freedesktop.org/cgi-bin/viewcvs.cgi/xorg/xc/programs/Xserver/hw/xfree86/drivers/via/via_dri.c?rev=1.4&view=log
Comment 13 Joshua Baergen (RETIRED) gentoo-dev 2005-11-20 10:59:28 UTC
As far as I can tell this has all been added to the newest (modular, at the very
least) via driver.
Comment 14 Joshua Baergen (RETIRED) gentoo-dev 2005-11-20 10:59:50 UTC
Fixed in 7.0.
Comment 15 Donnie Berkholz (RETIRED) gentoo-dev 2005-11-20 11:33:37 UTC
unichrome.sf.net is a separate driver from via, and we will probably add it to
the tree at some point.
Comment 16 Herbie Hopkins (RETIRED) gentoo-dev 2005-11-21 04:38:00 UTC
Comment on attachment 33370 [details, diff]
xorg-x11-6.7.0-r1.ebuid patch to provide unichrome drivers

Marking this obselete as it's clearly not the way to go.

Re comment #15:
To clarify,  unichrome.sf.net is an independant implementation partialy based
on some (cripled) code released by via and is in no way endorsed by or
supported by via. An older snapshot did get incorporated into xorg cvs but I am
unsure how functional it is. unichrome.sf.net development is very unsettled at
the moment due to a spat between a few of the core developers leading to a
fork, openchrome.org. XvMC support and support for unichrome pro chipsets
(K8M800 etc) has been removed entirely from the unichrome.sf.net driver whilst
the openchrome.org code retains all this functionality.

In short I am unsure which is the way to go in portage at the moment.
Comment 17 Donnie Berkholz (RETIRED) gentoo-dev 2005-11-21 10:29:23 UTC
(In reply to comment #16)
> Re comment #15:
> To clarify,  unichrome.sf.net is an independant implementation partialy based
> on some (cripled) code released by via and is in no way endorsed by or
> supported by via.

Yes. By "separate driver from via" I mean the driver is independent of the
driver called "via" in X.Org. If I meant it was released by VIA, I would have
capitalized it.

Thanks for the extra details, though.
Comment 18 Donnie Berkholz (RETIRED) gentoo-dev 2006-04-19 21:28:45 UTC
It should be pretty easy for someone to create an ebuild using the x-modular eclass. It should require few changes from the xf86-video-via driver, mainly SRC_URI, HOMEPAGE and DESCRIPTION.
Comment 19 Donnie Berkholz (RETIRED) gentoo-dev 2006-04-20 14:09:47 UTC
No particular interest in maintaining this.
Comment 20 Chris Mayo 2006-12-17 07:59:07 UTC
Created attachment 104209 [details]
xf86-video-unichrome-0.2.6.ebuild

Here's an attempt based on the via driver.

There is some benefit to having this, the via one is restricted in the dot clocks it can support, which is a problem when trying to drive a HDTV.
However, xvmc support was stripped out - probably making openchrome.org a better option depending on what you want to do.If only they would do releases (Bug 147425)!
Comment 21 Jakub Moc (RETIRED) gentoo-dev 2006-12-29 10:44:32 UTC
*** Bug 94807 has been marked as a duplicate of this bug. ***
Comment 22 Rémi Cardona (RETIRED) gentoo-dev 2009-07-28 15:47:02 UTC
The Gentoo/X team isn't interested of maintaining this driver. We'll help with eclass/ebuild questions but we don't have enough man power to maintain yet another driver.

If anyone is interested, this driver should probably go to Sunrise.

Thanks
Comment 23 Rémi Cardona (RETIRED) gentoo-dev 2009-07-28 15:49:36 UTC
*** Bug 96123 has been marked as a duplicate of this bug. ***
Comment 24 Jeroen Roovers (RETIRED) gentoo-dev 2011-04-18 14:51:45 UTC
It's dead. The openchrome project has better support (DRI implemented here and there, KMS soon to come, and more) for more cards (even OLPC specific hardware) and is actively developed.