Change

IT WORKS!!!!

First off, I want to thank Ivor (orv on these forums) of the Unichrome open-source driver project (http://unichrome.sf.net) for his work on the project and his pointers in the right direction.

Now, here's how I got this working under Debian Sarge:

From this site I got the basic info on how to get the X source package downloaded and building (which you must do to get this working).
Make sure you've run apt-get update and apt-get dist-upgrade recently to get everything up-to-date. Then (I did this in /usr/local/src) run "apt-get source xfree86" followed by "apt-get build-dep xfree86". Change into the xfree86 directory that was created by the source package download, and run "dpkg-buildpackage". This doesn't need to complete, but it has to get pretty far along. Grab a sandwich and a nice glass of water, and a cookie. I reccomend oatmeal with chocolate chips, but this isn't critical to the build process.

In another shell, changedir to /usr/local/src/xfree86-blahblah/build-tree/xc/programs/Xserver/hw/xfree86/drivers/via
When you can successfully run "make" in this directory with no errors, the X build process is far enough along, and you can terminate it.

Next, I followed the directions on this page to get the latest CVS source.
Back up one directory level to /usr/local/src/xfree86-blablah/build-tree/xc/programs/Xserver/hw/xfree86/drivers
Run "cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/unichrome co xfree86"
Then "rm -rf via" and "mv xfree86 via" (or "ln -s xfree86 via" as is listed in the directions...up to you).
Go into the via directory, edit "via_mode.h" and search for the ViaDotClocks section. Add the following line (not sure if it has to be in order, I inserted it into the appropriate place just in case): "{ 31746, 0x1733, 0 },". This sets up the correct dot clock register for the modeline Xenarc reccomends in their FAQ.
Now save and exit the editor, and "make". Should build successfully. "cp via_drv.o /usr/X11R6/lib/modules/drivers".
Now make sure you're using the modeline listed in the Xenarc FAQ, "Modeline "800x480" 31.746 800 860 940 1000 480 508 511 525 -hsync -vsync".

Oh, and also make sure X is now set up to use the via driver instead of VESA or whatever you may have been using before.

Hmm, suppose I should set up a web page with example files and such. I'll probably do that in a week or so when I'm less busy.

If you have problems I'm not sure how many questions I can answer, I got all this figured out after a few days' worth of stumbling through Google.

And no, I still have no idea how you'd get this working in Windows, and I don't know what steps would be different for Red Hat, Mandrake, SUSE, Slackware, Gentoo, or any of the other distros out there, or how to get it working with Lilliput monitors.

MP3Car.com

 

orv

Cool.
Now do all those who questioned my assertion that this was simple to do... get to wear T-Shirts printed with "Linux rocks, VIA sucks" ?

darkciti

Via can't suck that bad, they're hackable!

Anyone tried this with x.org? It should work considering it's just a Modeline adjustment to the driver...

__________________
http://carputers.org/

Gobby

I s'ppose it proves one thing, its just a driver that needs sorting not the BIOS.

Change

The Unichrome drivers were derived by reverse-engineering the old VIA binary drivers, if I remember right.

And yeah, should work with X.org. Not quite a modeline adjustment, involves adding another entry to the dotclock lookup table, but yeah.

orv

The unichrome driver works fine on x.org, that's what I do all my development on. In fact as long as you're not using a unichrome-pro board then the current xorg cvs contains an up to date driver already.


You have got to be kidding! They don't suck because its possible for amateur developers to achieve what they claim is impossible and have been "researching" for months?! ROFL.

Change - FYI you don't need to fiddle about building the driver inside the X tree, you can build it in its own directory, which makes keeping things updated simpler.

....and finally when you have found the best clock settings, please report them to the unichrome list.


Cheers,

PS

It's a bit more complicated than that. But in brief, the drivers are based on the original 'lite' via driver source they released a few years ago, the mpeg code had to be reverse engineered because VIA refuses to release the details because they are a "commercial secret", details of the video registers were also not released and had to be deduced, and the free modes code was written by trial and error by Luc Verhaegen.

Change

Hmm. I couldn't get it to build on its own, I had to get X building, then replace the VIA driver source with the Unichrome source, then re-make the makefile for the driver, and then finally make it. Otherwise it wouldn't build.

xga

Wow! Well done Change. I can't wait until the day when I check the 'LCD/Display' thread and see the post '800x480 SUCCESS in Windows with VIA onboard video!'.

You'd think that if you can get 800x480 working on linux by only playing around with the driver config files, that you should be able to get 800x480 in Windows using PowerStrip as you've proved that it's not a BIOS issue. Doesn't make sense to me....

MP3Car.com

 

orv

You'd need an updated windows driver too....

damageboy

I've taken a look at the newly released via open source driver for Linux 2.6
and it seems to have partial support ofr 800x480 built-in to it (i.e.:
no patching via_mode.h).
apart from that, it also looks while 800x480 support exists there, some 800x480 is commented out as well in viamode.h (as opposed to via_mode.h).

Anyway, has anyone tried to mess around with that driver? It seems to have full support for MPEG2/AGP/3D/DRI etc.

I'll try to work with both drivers + X.org on ubuntu this weekend, just wondering if someone can save me the time & effort

orv

It doesn't include the source code for mpeg2 support - it contains a binary only library, and the only S/W that can use it are the special Via versions of xine (VeXP) and mplayer (VeMP). It also still retains all of the bugs that the unichrome developers have fixed over the past two years.

I have no idea if it works or how well since I don't know anyone who's bothered using it.... or actually managed to build it on a recent 2.6 kernel.
however, I believe the VIA driver is STILL limited to supporting modes that are provided by the BIOS.


The only "patching" that is required is to add a clock number. Once valid clock values are reported to the unichrome list (so far non have been reported by anyone) then they can be included in the driver.
When we have enough information, we might then be able to completely autogenerate them... or if that's not possible we could just provide an ability to soft code them in a config file.


Why bother? But go for it if you like. It would be interesting if you reported back details of your experience.

damageboy

Hey Ivor, thanks for the detailed reply!
I wasn't suggesting that the big bad patch is a scary one... sorry if it came off that way.

I've already done the DotClock change suggested above for the basic source deb files for xorg which come with ubuntu "hoary" 5.04, and it seems to be working well...

I was/am mostly wanting to compare both drivers in terms of performance to see which one does a better job...
I'm mostly interested in plain 2D performance for media frontend + visualizations.
If I find anything exciting I'll let you know.

zots

IF BSP_DISPLAY_VIA

; @CESYSGEN IF CE_MODULES_PCI

; Added by Yapi,2002-06-25 , For SetMode by Registry Function

[HKEY_LOCAL_MACHINE\System\GDI\Drivers]
"Display"="ddi_via.dll"
;
; VIA driver settings
;
[HKEY_LOCAL_MACHINE\Drivers\Display\VIA]
;; Support DisplayDevice
;1 : CRT
;2 : LCD
;4 : TV
;8 : DVI
;10: HDTV
;; If set CRT + LCD, DisplayDevice = 3
;; If set CRT + TV , DisplayDevice = 5
;; If set CRT + DVI, DisplayDevice = 9
;; If set CRT + HDTV, DisplayDevice = 11
"DisplayDevice"=dword:1

;; Panel Size Index Setting for LCD, include PanelSize, Dual/Single, Dithering
;0: 640x480, single, dithering
;1: 800x600, single, dithering
;2: 1024x768, single, dithering
;3: 1280x768, single, dithering
;4: 1280x1024, dual, dithering
;5: 1400x1050, dual, dithering
;6: 1600x1200, dual, dithering
;7: 1280x800, single, dithering
;8: 800x480, single, dithering
;9: 1024x768, dual, dithering
;A: 1024x768, single, nodithering
;B: 1024x768, dual, nodithering
;C: 1280x768, single, nodithering
;D: 1280x1024, dual, nodithering
;E: 1400x1050, dual, nodithering
;F: 1600x1200, dual, nodithering
;; When CRT + LCD , must set Panel Type here.
;; If Panel Type setting is not the actual correct size , it will not set LCD on.
"LCDPanelSizeIndex"=dword:2

;; Panel Centering or Expanding setting
;0: Center
;1: Expand
"PanelCenter"=dword:0

;; Mobile or DeskTop
;0: DeskTop
;1: Mobile
"IsMobile"=dword:1

;; For Atrium Customer. Support LVDS 12DDR
;0: None
;1: Yes
"Atrium"=dword:0


If wince5.0 has support, why not xp?

via should work on providing the support for 800x480 support in xp drivers.

damageboy

As people HAVE mentioned before, the Windows XP driver does support 800x480 only with no acceleration of graphics.
I suspect the same it tru for windows ce.

keanpedersen

I got this working, and can verify the 800x480 outout with a normal monitor, but my lilliput doesn't show anything with this modeline. So I guess the mode only works for xenarc screens? Does anyone have a working modeline for lilliput?

MP3Car.com