The IBM PC110 is a C&T 65530 SVGA controller with 512kb of RAM. Running Xconfigurator and following the defaults it gets to starting X to test it - screen goes blank and its goodbye time. Using --preferxf3 X starts and then bombs out because 16bpp isnt available but is offered by the configuration tools. Fixing that I get a mangled display and it runs _incredibly_ slowly. The text mode restore leaves mess on the display This used to work with older XFree 3.3.x - Im still trying to find out if its some magic in the old Xconfig or not.
This seems to be a build bug: I quote from the log (II) Loading /usr/X11R6/lib/modules/libramdac.a (II) Module ramdac: vendor="The XFree86 Project" compiled for 4.0.3, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.3 Symbol XAAInitDualFramebufferOverlay from module /usr/X11R6/lib/modules/drivers/chips_drv.o is unresolved! Symbol XAAFillSolidRects from module /usr/X11R6/lib/modules/drivers/chips_drv.o is unresolved! Symbol XAAFillSolidRects from module /usr/X11R6/lib/modules/drivers/chips_drv.o is unresolved! (II) do I need RAC? No, I don't. (II) resource ranges after preInit: With 3.3.6 it works but needs some strange mode entries: Section "Device" Identifier "PC110 SVGA" VendorName "Chips & Technologies" BoardName "65535"Section "Monitor" Identifier "PC110 LCD" VendorName "CITIZEN" ModelName "L6481L-FF" HorizSync 10-40 VertRefresh 15-80 Modeline "640x480" 15.00 640 672 728 816 480 489 496 526 EndSection I guess we could add a monitor entry for it under the LCD screens but the other stuff with texmode magic I think is too box specific and weird to expect Xconfigurator to get that right:- Chipset "ct65535" VideoRam 512 TextClockFreq 15.00
Not a build bug, but a driver bug. It seems that a fair number of the XFree86 drivers do not have the proper symbol inclusions. I just fixed this one for 4.0.3. Will send a patch upstream. I wish X would auto detect what symbols are used during build time and auto-include them. It seems this is a VERY frequent bug in ALL drivers. ;o( I don't know if this will fix the problem you're encountering, but it might. This patch will be in my next build of 4.0.3.
Alan, I'm building -18.1.0 right now, can you check it out tomorrow or soon, and let me know if it fixes the problem? I believe the missing symbols are fixed. Also, about a month ago I contacted the Stanford "Checker" people on lkml and asked them if they'd considered doing such a thing for XFree86 which ended up getting the ball rolling. They now are working on a checker for XFree86. ;o) I just sent them a message to see if they can add some snazzy code to check for missing symbols in X drivers. If implemented I think it will solve a fair number of driver bugs. Let me know if the new X build works for you. You'll need glibc 2.2.3 I believe to use it.