Status Report Intel D201GLY and DSL 4.1 (video)

Forum: X and Fluxbox
Topic: Status Report Intel D201GLY and DSL 4.1 (video)
started by: mhatch

Posted by mhatch on Dec. 10 2007,18:44

Haven't seen any other postings on the Intel D201GLY in the DSL forums, so thought I would share my experiences.

If the D201GLY is an unknown board to you, the basics is that it is an Intel MB with a Celeron chip soldered in with SIS North/South Bridges. It comes in two forms: V1 is PATA only and runs with a faster (but hotter) CPU that requires a fan. V2 appears to be more desirable as it is fanless and includes two SATA plugs. The boards use the SIS 662 (mirage 1) video chip and includes one memory slot (up to 1gb) and one PCI slot. Not bad for $70-$80!

The good news is that DSL 4.1 boots and runs X with no problem! The Vesa Video driver works fine (if you like unaccelerated video and accept horizontally stretched display on a wide screen LCD). I have not confirmed Audio, but have not seen any problems reported for other distros.

The challenge is getting an accelerated video driver to work with DSL. The standard sis driver included with the DSL XFree86 packages only partially works for me (1680x1050 - 22inch) - I get a lot of horizontal lightning. (This appears to be a performance issue, see for example: < > )

The ubuntu folks seem to have been the most successful here. See:

< >

They have found a copy of the original Intel drivers for RH, and have found that SuSE 10.2 also includes them.

Probably the most promising (at least as reported on the ubunto forum above), are the "premium" sis drivers released by Dr. Thomas Winischhofer. See:

< >

The ubuntu folks have had good luck rebuilding the drivers for X11R7 from (See build instructions at:

< >

The remaining question is whether this code can be made to work with the XFree 4.3 we use. I am going to give it a try... If anybody else has been down this path, please let me know.


Posted by curaga on Dec. 10 2007,18:57
Just a note: Vesa can use widescreen resolutions too.
Check with "Xvesa -listmodes", if it lists 1680x1050x your bit depth, it can be used, both as framebuffer console and X resolution..

Posted by mhatch on Dec. 10 2007,20:10
Thanks for the suggestion. Unfortunately, listmodes for the sis662 only comes back with 4:3 sizes e.g. 1600x1200 and 1280x1024,etc.

For some reason my Chimei 22 accepts that resolution, just is clear that it is not the "preferred" 1680x1050. :-(

Tried the "-force" option with 1680x1050, that didn't do anything.

Now in the middle of trying to compile the driver, and of course, the configure file assumes :-(


Posted by ^thehatsrule^ on Dec. 11 2007,00:11
What about the newest "free" drivers in < > ?  There's binary downloads so you don't even have to compile it.

For the configuring, always read the README/INSTALL/etc files, and ./configure --help can also be of help.

Of course you could always use xorg instead, but I suppose you're trying to use xf430 for a reason.

Posted by mhatch on Dec. 11 2007,02:29

Actually, I have no particular reason to try to remain with the xf4.3.0 release... (although the binary provided by the link above was a small improvement over the sis driver provided with xf 4.3.0).

So tonight, I actually tried the xorg 7.2 uci that you have made available in the testing area. (Thanks!)

My plan "A" was that the SIS driver with 7.2 would be a notch better. Unfortunately, the horizontal lightning still remained.

My plan "B" was to try to wedge in the sis driver the ubuntu people had built for xorg 7.2. Unfortunately, that plan also died because they used a newer gcc that required glibc 2.4.

So plan "C" is to rebuild the latest premium driver. However, in re-reading Winishhofer's notes on building the standard driver from source, it looks like I will need to set up a whole 7.2 source tree, and then slam his driver source in the appropriate SIS directory. I will have to think about that one a little...


Posted by ^thehatsrule^ on Dec. 11 2007,03:29
In such cases, reduce the resolution and/or refresh rate and/or color depth, or use one output (CRT1 or CRT2) only.
Did you try any of those?  I'm guessing you'd want to try reducing the refresh rate and/or color depth (try 16-bit).

C. Those notes don't apply to XOrg 7.0+ (and are for the non-features version).  There's some compiling steps for sisp.tar.gz on that Ubuntu thread, though you'll have to find out what dependencies you'll have to install (probably xorg72-dev will be of interest).

Posted by mhatch on Dec. 11 2007,04:03
Thanks for keeping with me here....

I tried reducing resolution to 1280x1024  (didn't help) Maybe an even lower resolution would help, but I would rather live with Vesa before doing that. Going down to 8 bit color helped, but was not very pretty...

Did try following the ubuntu steps after grabbing your dev libraries, but I think my newbie status is getting in the way and I didn't put things in the right place...

It looks to me like what I really want is to overlay the development tar ball onto the existing /opt/xorg72 directory structure so that /opt/xorg72 includes the include directory and the lib includes the pkg information. At that point, I think the ./configure would set things up right and the compile would generate the pages of compile errors (undefines...) that I am getting.

The one problem is that xorg72 uci is mounted ro and so just unpacking the tar ball on top of /opt doesn't get me far... RTFM suggestions gladly accepted...


Posted by ^thehatsrule^ on Dec. 11 2007,04:17
You can copy the directory in /opt to another one, i.e. to be stored on ramdisk.  Then uninstall the uci, and rename the folder back to it's original.  These instructions are posted somewhere as well...
Posted by Juanito on Dec. 11 2007,04:46
I found this to be a handy way to work when building programs that require multiple compilations. When you have to stop part way to do something else, you can make a quick .uci and then load, copy, unload & copy back to start-up where you left off.

In this particular case:
Code Sample
$ mydsl-load /path/xorg72.uci [1st time loads extension]
$ sudo cp -r /opt/xorg72 /tmp
$ mydsl-load /path/xorg72.uci [2nd time unloads extension]
$ sudo cp -r /tmp/xorg72 /opt
$ sudo rm -r /tmp/xorg72 [optional]
$ mydsl-load /path/xorg72-dev.tar.gz

Posted by mhatch on Dec. 11 2007,05:41
Thanks for both suggestions! I got passed that newbie roadblock, on to the next one. ;-)

I am now tracking down dependencies (as predicted).

The ./configure initially failed on the lack of a libdrm.pc in the pkgconfig directory. However, does live in the xorg72/lib directory, so I set the appropriate linker/compile flags environment variables to bypass that one.

But during the make, I am getting a bunch of syntax errors out of xorg72/include/GL/glxint.h... Given they are "missing type" errors it *looks* like  it might be do to a missing header file. And specifically it looks like "GL/gl.h" is MIA (ran a quick find, and didn't find it...) Suggestions?


Posted by Juanito on Dec. 11 2007,06:12
mesa-6.5.2 was used to build xorg72 and gl.h was generated while building mesa.

I did not include the mesa headers in xorg72-dev because I didn't think about it at the time. Thinking about it now, the xorg72 compilation uses the mesa sources for its own purposes but does not depend on mesa directly so I'm not sure whether the mesa headers belong with xorg72-dev or not.

You could get the headers by compiling mesa-6.5.2 or, if you drop me a pm, I could send you the tarball.

If somebody who understands these things better than me could given an opinion on the subject, I could add the mesa headers (libs as well?) to xorg72-dev.

Posted by ^thehatsrule^ on Dec. 11 2007,06:18
$ sudo cp -r /tmp/xorg72 /opt
$ sudo rm -r /tmp/xorg72 [optional]
Could use mv instead?

You could add them, or even create another extension (that suggests the xorg72-dev package).  I call it entirely up to you, since the xorg72 package itself isn't split up.

Posted by curaga on Dec. 11 2007,07:49
Well, they are essential in building apps that use opengl..

Having a separate extension would allow compiling those with only base DSL.

Posted by mhatch on Dec. 12 2007,13:00
Thank you for the Mesa tar ball, that got me passed that one.

I am now missing the drm headers. (xf86drm.h and friends). Is it normal for an distro to reference XFree headers?


Posted by Juanito on Dec. 12 2007,13:12
...and yes, libdrm-2.3.0 was used to build xorg72 and contains drm.h xf86drm.h etc - I guess I should have thought to include these with the mesa headers since mesa reuired drm to build.

I'm travelling at the moment, so I cannot double-check exactly what is compiled by libdrm for a couple of days.

Posted by mhatch on Dec. 13 2007,13:34
Did get it to compile & link. (Thanks again for all the help!). Ran into a known problem reported on the Unbuntu group (missing xorgGetVersion() symbol). Looks like a pretty easy workaround.

Should have more news to report over the weekend...


Posted by mhatch on Dec. 15 2007,14:35
Fixed the unresolved symbol and started x. Got a Xserver crash 8...

Backtraced showed that it originated from within the SIS driver. Died in a font file routine (looks like it was done reading a font file).  No luck googling the error messages (very common way for xorg 7.2 to die).

Given that the ubuntu people did not report anything similar, (and with the old sis driver, X started fine, so the fonts files are obviously OK) I am guessing a version incompatibility with one of the component libraries used by the driver vs X itself.

Comments on this logic? I am thinking of trying to build X from scratch and inject the sis driver in the source tree. Any reason that there is not a xorg 7.3 addon?


Posted by curaga on Dec. 15 2007,15:05
Because no-one has done it..
Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.