cincin77
asked on
embedded pc - xwindows problem
Hi,
I have an embedded computer.(advantech pc5820 series). I have an external HD connected to it. I installed Mandrake 8.0 on it.
The graphic card chipset used on this machine is a NS CX 5530 1-4MB UMA share memory. and Mandrake doesn’t list the NS geode as compatible on their website
so i could not choose a graphic card during the installation. The support engineers of Advantech sent me a XFree86 driver for their card.
I have a great problem with the documentation that comes with the driver:
in the release.txt which comes with the driver, it tells to install Xfree86 server. i downloaded the binaries of 4.0.1 and installed them.
in section 2 of release.txt, it tells to build the X11. (does it mean to install?????)
then it talks about 2 copy jobs. both of them replaces the same file;/etc/X11/XFree86Confi
when it comes to install (section 4), it talks about crlf which does not mean anything to me.
also it again talks about inflating v4.0.1 bz files; i have already installed xserver so what does it talk about?
it talks about xc tree? does it come with the xserver sources or with the driver sent to me? if the first one, i installed using the binaries?
should i reinstall using sources? If second, why does it talk about an installation? i have not installed the driver yet.
then for non-stb (i think it is my case), it talks about 2 copy jobs which are to directories that do not exist. should i create them?
it talks about durango directory which does not exist. there is a file durango.c in gfx directory. and also there are more than one gfx directory.
I am at this stage. i could not continue, because i am really confused.:(((
I send this release.txt with this mail.
I will appreciate your comments. How can i install this driver?
thanks in advance.
best regards.
I have an embedded computer.(advantech pc5820 series). I have an external HD connected to it. I installed Mandrake 8.0 on it.
The graphic card chipset used on this machine is a NS CX 5530 1-4MB UMA share memory. and Mandrake doesn’t list the NS geode as compatible on their website
so i could not choose a graphic card during the installation. The support engineers of Advantech sent me a XFree86 driver for their card.
I have a great problem with the documentation that comes with the driver:
in the release.txt which comes with the driver, it tells to install Xfree86 server. i downloaded the binaries of 4.0.1 and installed them.
in section 2 of release.txt, it tells to build the X11. (does it mean to install?????)
then it talks about 2 copy jobs. both of them replaces the same file;/etc/X11/XFree86Confi
when it comes to install (section 4), it talks about crlf which does not mean anything to me.
also it again talks about inflating v4.0.1 bz files; i have already installed xserver so what does it talk about?
it talks about xc tree? does it come with the xserver sources or with the driver sent to me? if the first one, i installed using the binaries?
should i reinstall using sources? If second, why does it talk about an installation? i have not installed the driver yet.
then for non-stb (i think it is my case), it talks about 2 copy jobs which are to directories that do not exist. should i create them?
it talks about durango directory which does not exist. there is a file durango.c in gfx directory. and also there are more than one gfx directory.
I am at this stage. i could not continue, because i am really confused.:(((
I send this release.txt with this mail.
I will appreciate your comments. How can i install this driver?
thanks in advance.
best regards.
ASKER
oopsss sorry; i copied and pasted the above text from a mail.:)) here is release.txt:
Xfree 4.0.1 Graphics Device Driver.
Release 1.2.0
Linux Kernels used: 2.4.0 and 2.4.17.
May 16th, 2002
--------------------------
1. PRODUCT INFORMATION
--------------------------
This driver is the Xfree 4.0.1 Graphics device driver for the Gx1 processors.
Display modes supported by GX1 and SCx200 processors
- 640x480 @ 60, 72, 75, 85Hz , 8 and 16 Bpp
- 800x600 @ 56, 60, 72, 75, 85Hz , 8 and 16 Bpp
- 1024x768 @ 60, 70, 75, 85Hz , 8 and 16 Bpp
- 1280x1024 @ 60, 70, 75Hz, 8 Bpp
Modes supported only in Pyramid
- 1280x1024 @ 85Hz, 8 Bpp
- 1280x1024 @ 60, 75, 85Hz, 16 Bpp.
The Geode driver has support for 2 PAL ("PAL-768x576", "PAL-720x576")
and 2 NTSC("NTSC-640x480", "NTSC-720x480") TV Modes Apart from the
CRT Modes defined above.
The TV Modes works only in 16 BPP. So, while testing the TV Modes, the Display
should be set for 16 BPP.
TV MODES ARE SUPPORTED ONLY ON PLATFORMS WITH SC1200 AND SUPPORTED HARDWARE
LIKE CYGNUS.
The Geode Driver can also support DSTN, SSTN and TFT Panels. The Panels
have been tested on Centaurus and Dorado Platforms.
Pixel rotation supported giving the portait look of the Framebuffer
in clockwise or anti-clockwise direction.
DPMS supported for Display power management.
Direct Graphics Acceleration(DGA) supported
TV Overscan Supported.
Xfree 4.0.1 FBDev driver
XFree FBDev driver is a non-accelerated XFree graphics driver for National
hardware. It is completely dependent on the underlying NSC Kernel
frame buffer driver (KFB) to switch modes and rendering geometry.
This is one of the simplest forms of the graphics driver provided by Xfree.
Xfree FBDev driver dont support features like dga, Rotation, video, panel,
TV Overscan.
To understand the usage of various components of XFree86 4.0.1 driver look
into the "$/Engineering_Releases/dr
/packing_distribution.doc V0.0.2" in VSS "video" database. This document
explains the drivercomponents STB, Non STB and XFBDEv.And it gives the
interface XFree driver with the Kernel Framebuffer driver(KFB driver)
--------------------------
2. INSTALLATION INSTRUCTIONS
--------------------------
There are many significant changes to XFree86 reflected in the 4.0.1 release.
- To use XFree86 4.0, download the source from: http://www.xfree86.org/
or
you can get a copy from the VSS at
"\\video\engineering_relea
- If you have XFree v3.3.6 installed in your system. Before inflating the v4.01
*.bz files, rename the /usr/X11R6 directory as /usr/X11R6.336.
- Change directory to /usr/bin, "rm -rf X11"
- Change directory to /usr/lib, "rm -rf X11"
- Change directory to /usr/include, "rm -rf X11"
- Now extract the *.bz files in the directory desired.
- Pl. follow the build instructions for building the XServer.
- There is only one Xserver in 4.0: XFree86. It will load the modules/drivers
that it needs at run-time. These drivers are located at:
/usr/X11R6/lib/modules/dri
- Pl. use the XF86Config file supplied to you.
1. Copy XF86Config.geode to /etc/X11/XF86Config for both STB and non-STB
configurations.
2. Copy XF86Config.fbdev to /etc/X11/XF86Config for Xfree86 4.0.1 FBDev driver.
FBDev uses the resoultion set by the Framebuffer.
--------------------------
3.Understanding the Xserver
--------------------------
The Xserver manages client connections and responds on behalf of clients
to user interface events (mouse, keyboard input) and protocol requests
(graphics). It is divided into 4 major pieces:
- device independent layer (DIX): code shared among all implementations
- OS layer: code which is different between operating systems but shared
among all devices of an operating system
- device dependent layer (DDX): code which is potentially different between
operating systems and graphics devices
- extension interface: the standard way to add features to the X server
For more information on this, see the xc/doc directory.
--------------------------
4.BUILD INSTRUCTIONS
--------------------------
- These instructions are laid out based on the assumtion that you have a
Redhat 6.2 installation. You may have to skip few of the steps other
than Redhat installation.
- Build and install crlf utility. For more information look at readme.txt in
crlf provided.
- crlf on all the code provided. Read the crlf usage in the crlf/readme.txt.
- If you have XFree v3.3.6 installed in your system. Before inflating the v4.01
*.bz files, rename the /usr/X11R6 directory as /usr/X11R6.336.
- Change directory to /usr/bin, "rm -rf X11"
- Change directory to /usr/lib, "rm -rf X11"
- Change directory to /usr/include, "rm -rf X11"
- Now extract the *.bz files in the directory desired.
- After the 'xc' tree is created, copy the files under revision control into
their respective places in the 'xc' tree.
- move to xc/programs/Xserver/hw/xfr
- If you are building the Xserver for Set-Top-Box solution with "GAL" and
"Framebuffer". Rename the Imakefile.stb as Imakefile.
Build the Framebuffer and GAL for Set-Top-Box solution.
- If building for a standalone Xserver for
Tinclient or Webpad solution. Rename Imakefile.pad Imakefile.
- Pl. follow the bellow 2 steps for NON-STB SOLUTION ONLY.
1. Copy the contents of the Durango directory which is specified
in the release notes into
"/usr/X11R6/xc/programs/Xs
2. Copy the contents of the Panel library which is specified
in the release notes into
"/usr/X11R6/xc/programs/Xs
- There is only one Xserver in 4.0.1 XFree86. It will load the modules/drivers
that it needs at run-time. These drivers are located at:
/usr/X11R6/lib/modules/dri
- Frame buffer is must for SetTopBox Solution and XFree 4.0.1 FBDev driver.
- To Build the Frame buffer driver Pl. follow the Frame buffer install and
build instructions as per readme.txt.
- GAL Library(REQUIRED FOR SetTopBox Solution ONLY)
For the XServer to compile you require libgal.a. To build a GAL library Pl.
follow the GAL install and build instructions.
- To initiate a full build, switch to the '<install dir>/xc' directory.
Enter 'make World >& world.out'. This will start the build process.
If all of the configuration parameters are correct,
this step will only needed once.
- After Successful make, Enter 'make install' to install X11.
- switch to geode dir
"cd <install dir>/xc/programs/Xserver/h
- Execute "make install" from the geode directory. This builds only the
geode module.
- The X binaries are placed under "/usr/bin/X11" and make sure you have this
directory in your path.
- Now to setup the font direcories correctly "cd /usr/lib/X11/fonts/misc".
execute "mkfontdir" here to setup the font directories.
Configuring the Xserver
--------------------------
Working XF86Config file is attached and should be used.
Before configuring the Xserver, copy /etc/X11/XF86Config to XF86Config.bak.
A Geode mode specific XF86Config is supplied to install this copy the supplied
XF86Config.geode to /etc/X11/XF86Config.
Different Options in XF86Config (For sTB and Non STB solutions):
--------------------------
To enable H/W compression, Option "Compression".
Cursor option:
Cursor can be drawn either Hardware or Software.
1.To enable Software cursor, Uncomment the Option "SWcursor" and comment
the option "HWcursor".
2.To enable HW cursor, Uncomment the Option "HWcursor" and comment the
option "SWcursor".
Default HWcursor will be enabled.
DGA option:
1.To enable DGA, Uncomment the Option "xfree86-dga" and comment
the option "omit xfree86-dga".
2.To disable DGA, comment the Option "xfree86-dga" and uncomment
the option "omit xfree86-dga".
Default DGA will be selected.
DGA is disabled if TV Overscan is enabled.
CRT mode option:
OffScreen Memory option:
To use Offscreen FrameBuffer memory, Uncomment the Option "OffScreenMemory".
Default this option will be enabled.
CRT mode option:
Default Monitor Depth set to 16 bit.
Default crt modes are in the order "1280x1024","1024x768","80
and "640x480".
Driver selects the highest resolution supported by the hardware in the
above order.
If the selected hardware mode is not supported by the Monitor. The user
will get a blank screen or a garbage on the screen. If this happened
Comment the highest display mode (e.g "1280x1024") and test again.
Repeat this till Hardware CRT display mode and Monitor supported mode
compatible.
Note: If a TV mode option set and if it is a TV supported platform
the CRT modes will be ignored.
TV mode option:
To Enable 768x576 Pal Mode, In the XF86Config file,
Option "TV" "PAL-768x576" parameter should be set.
To Enable 704x576 Pal Mode, Option "TV" "PAL-704x576" parametershould be set.
For NTSC mode, Option "TV" "NTSC-640x480" or "NTSC-720x480" should be set.
Once the TV option selected the CRT mode options are ignored,
even the CRT mode option are set.
Flat Panel option:
To Enable the Panel Option,"Option FlatPanel" should be set.
To disable the panel, Option "FlatPanel" has to be commented out.
Panel h/w can be initialized in two ways.Initialization done by BIOS, or done
by the driver ONLY FOR NSC PLATFORMS.
To initialize the panel using BIOS set,the Option "Flatpanel" and
Option "FlatPanelInBios".If Bios doesn't support the panel, panel will be
disabled, only CRT will be enabled.
Use Option "Flatpanel" only in case of NSC platform.
If platform supports panel, panel will be enabled.
Make sure when Panel is enabled, only one resolution is supported.
We can't have Multiple resolutions.
When TV is enabled, Panel support is automatically disabled.
Rotation option:
To enable Framebuffer rotation clockwise, Option "Rotate" "CW" is used.
To enable Framebuffer rotation counter clockwise, Option "Rotate" "CCW"
is used.
The portrait mode operates slower for all functions.
In portrait mode Acceleration is turned off and co-ordinate transformation
also takes place.
All this is being done in software, which adds extra delay.
The user sees everything slower in portrait mode.
Drawing operations will be slow in non-accelerated driver.
Non-Accelerated driver is slow with respect to accelerated driver.
Tv Overscan option:
Tv Overscan will work on platforms like cygnus which support TV.
To enable TV Overscan, Option "TVOverscan" "xx:yy:ww:hh" is used.
In this option xx is the X-offset value
yy is the y-offset value
ww is the Width of the Screen
hh is the Height of the screen.
All the values should be >=0.
ww + xx <= resolution width
hh + yy <= resolution height
If any of the above conditions fails TVOverscan will be disabled.
DGA is disabled if TV Overscan is enabled.
In addition to the above options the Xfree86 4.0.1 driver supports the
options "ShadowFB",
"Overlay", "ColorKey" and "VideoKey".
- Run xinit or startx to launch the Xfree 4.0.1 driver.
Xfree 4.0.1 FBDev driver:
-------------------------
To build the Xfree 4.0.1 FBDev driver
- Build and install the FFrame buffer driver
which is specified in the release notes.
- Use the XF86Config.fbdev which is specified in the release notes.
- Run xinit or startx to launch the Xfree 4.0.1 driver.
--------------------------
7. UNIT TEST
--------------------------
Testing:
- The driver was tested on Centaurus, Dorado and Cygnus Platforms.
The TV modes are tested on Cygnus SC1200 Rev B board with a GX1 8.1 processor
and 64 Mbytes of RAM. XpressROM version v2.9.2 has been used to test this
version of driver.
- DSTN and TFT Panels have been tested on Centaurus and Dorado Platforms.
- Correct jumper settings has to be set on Centaurus and Dorado Platforms.
- For Dorado Platform:
fixed J61 jumper setings for flat panel - they are now:
J61 LCD Mode Selector Jumper
1-2 3-4 5-6 9-10 Type of LCD Panel
NS9211 NS9211 NS9211 NS9211
GPIO0 GPIO1 GPIO2 GPIO4
OFF OFF OFF OFF 800x600 16 Bit Color Dual STN
OFF OFF ON OFF 640x480 16 Bit Color Dual STN
OFF ON OFF OFF 1024x768 24 Bit Color Dual STN
OFF ON ON OFF 640x480 8 Bit Color Single STN
ON OFF OFF OFF 640x480 8 Bit Mono Dual STN
ON OFF ON OFF 1024x768 18 Bit Color TFT
ON ON OFF OFF 640x480 18 Bit Color TFT
ON ON ON OFF 800x600 18 Bit Color TFT
ON ON ON ON Flat panel disabled
- For Centaurus Platform:
fixed J14 jumper setings for flat panel - they are now:
J14 LCD Mode Selector Jumper
1-2 3-4 5-6 Type of LCD Panel
NS9211 NS9211 NS9211
GPIO0 GPIO1 GPIO2
OFF OFF OFF 800x600 16 Bit Color Dual STN
OFF OFF ON 640x480 16 Bit Color Dual STN
OFF ON OFF 1024x768 24 Bit Color Dual STN
OFF ON ON 640x480 8 Bit Color Single STN
ON OFF OFF 640x480 8 Bit Mono Dual STN
ON OFF ON 1024x768 18 Bit Color TFT
ON ON OFF 640x480 18 Bit Color TFT
ON ON ON 800x600 18 Bit Color TFT
- Run xinit or startx to launch the Xfree 4.0.1 driver.
- Run Xvtest application for Xv extensions.
- To test TV Overscan, Enable the Option "TVOverscan" "xx:yy:ww:hh"
in /etc/X11/XF86Config file.
--------------------------
8. VALIDATION NOTES
--------------------------
When the XServer is configured for portrait mode using Option Rotate, the
GNOME logout function will perform very slowly.
INFORMATION: Instead of using StartX to initialize XWindows, use Xinit, from
there run the window manager (ie KDE or GNOME). If using startx, you may need
to edit the xinit portion of the startx script to have xinit load a window
manager on startup. With RedHat 6.2, and XFree86 3.3.6, the path to the xinit
and startx commands is /usr/X11R6/bin. XFree86 4.0.1 stores these commands in
/usr/X11/bin, so necessary environment variables will also need to be updated.
--------------------------
9. REVISION HISTORY
--------------------------
Version 1.2.0. - (May 16th, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.2.0
GAL v1.2.0
Durango v2.41.02
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
- Driver tested on the Durango Version 2.41.02.
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
- geode_driver.c
- durango.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
Version 1.1.0b. - (April 18th, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.7b
GAL v1.1.4
Durango v2.41.01
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
- Driver tested on the Durango Version 2.41.01.
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
- None
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
Version 1.1.0a. - (April 16th, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.7a
GAL v1.1.4
Durango v2.35.01
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
- Driver tested on the Linux kernel Version 2.4.17.
- It supports all the functionality of the Driver v1.1.0 on the Kernel V2.4.17
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
- None
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
Version 1.1.0. - (Jan 20, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.6
GAL v1.1.4
Durango v2.35.01
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
--------------------------
DEFECTS CORRECTED
--------------------------
- Fixed the behavior of the TV Overscan on Non TV platforms.
- #81.23 Panel selection option in XF86Config file.
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.9 - (Dec 28, 2001)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.5
GAL v1.1.3
Durango v2.35.01
Panel v1.2.6
__________________________
FUNCTIONAL CHANGES
--------------------------
- Added TV Overscan support.
--------------------------
DEFECTS CORRECTED
--------------------------
- Panel selection problem was fixed.
- #81.15 Framebuffer and XFree readme.txt confusing.
--------------------------
FILE CHANGES
--------------------------
geode.h
geode_driver.c
geode_accel.c
geode_cursor.c
geode_video.c
XF86Config.geode
XF86Config.fbdev
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.8 - (Nov 8, 2001)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.4
GAL v1.1.3
Durango v2.35.01
Panel v1.2.5
__________________________
FUNCTIONAL CHANGES
--------------------------
- Added panel initialization either from BIOS or depending on NSC platform.
- Compression is provided as an option.
--------------------------
DEFECTS CORRECTED
--------------------------
-
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode.h
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.7 - (June 20, 2001)
Dependencies
crlf v1.0.0
Framebuffer driver v1.1.3
GAL v1.1.2
Durango v2.31.0
Panel v1.2.3
__________________________
FUNCTIONAL CHANGES
--------------------------
- Use gfx_set_display_bpp to set the BPP in both DP and GP.
--------------------------
DEFECTS CORRECTED
--------------------------
- 111.3 XVtest documentation does not match performance
- 81.5 Framebuffer and XFree readme.txt confusing
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.6 - (June 5, 2001)
Dependencies
crlf v1.0.0
Framebuffer driver v1.1.2
GAL v1.1.2
Durango v2.31.0
Panel v1.2.3
__________________________
FUNCTIONAL CHANGES
--------------------------
- Added acceleration for monochrome bitmap.
- Save and restore the complete h/w(tv, panel, CRT, compression, cursor)
--------------------------
DEFECTS CORRECTED
--------------------------
- 81.16
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode.h
geode_accel.c
geode_cursor.c
geode_video.c
Imakefile
durango.c
panel.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.5 - (March 15, 2001)
Dependencies
crlf v1.0.0
Framebuffer driver v1.1.0
GAL v1.1.0
Durango v2.26
Panel v1.2.0
__________________________
FUNCTIONAL CHANGES
--------------------------
-Modified the code to operate independently also of STB arch..
--------------------------
DEFECTS CORRECTED
--------------------------
- 81.16
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode.h
geode_accel.c
geode_cursor.c
geode_video.c
Imakefile
durango.c
panel.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.4 - (Feburary 3, 2001)
Dependencies
Framebuffer driver 1.09
GAL 1.0.5
__________________________
FUNCTIONAL CHANGES
--------------------------
-Added NTSC and PAL TV support.
-Added DSTN and TFT Flat Panel Support.
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
--------------------------
KNOWN ERRATA
--------------------------
- If the X comes up with Panel enabled, later even if you disable panel support
cursor panning still takes place.
--------------------------
--------------------------
version 1.0.3 - (January 08, 2001)
Dependencies
Framebuffer driver 1.09
GAL 1.0.4
__________________________
FUNCTIONAL CHANGES
--------------------------
-Added compression and dynamicaly position cursor offset.
-Enabled 1280x1024 16BPP mode.
-Added dynamic setting of Max suppoorted pixel clock.
-Added DGA support.
-Added ShadowFB and Rotataion support Clockwise or Counter-Clockwise.
-Added Panel Option support. Modified the GAL interface and removed galapi.h
and all the GAL protocols and struct definition moved to one single header
file galproto.h
-Added Panel parameters to the driver. Handle the Panel option appropriately
and fill the panel structure.
-Added DPMS support for geode driver. Currently only enable and disable are
supported. StandBy and suspend need to be done.
-Added Panel parameters to the driver. Handle the Panel option appropriately
and fill the panel structure.
-Panel Options added To trigger panel support enable
Option "Panel" "paneltype"
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode_dga.c
geode.h
XF86Config
galproto.h
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
--------------------------
Version 1.0.2 (November 2, 2000) Companion Framebuffer driver 1.07
and GAL version 1.0.3
__________________________
FUNCTIONAL CHANGES
--------------------------
- Graphics modeset now work from text modes too
- Added a new GAL stub to compile GAL with XFree driver as a module
- Xfree 401 has its own libc implementation which has to be used for
module support
- Added support for XFree 4.0.1.
- Restructured galproto.h to be independent of galapi.h
- Added (set/get)displaytiming and setpalette APIs
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
Version 1.0.1 (October 20, 2000) Companion Framebuffer driver 1.06
and GAL version 1.0.2
__________________________
FUNCTIONAL CHANGES
--------------------------
- Switched to using GAL
- Support for GAL 1.0.2
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
__________________________
Version 1.0.0 (September 22, 2000)
__________________________
FUNCTIONAL CHANGES
--------------------------
Initial version - supports Gxm, SC1200
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
Xfree 4.0.1 Graphics Device Driver.
Release 1.2.0
Linux Kernels used: 2.4.0 and 2.4.17.
May 16th, 2002
--------------------------
1. PRODUCT INFORMATION
--------------------------
This driver is the Xfree 4.0.1 Graphics device driver for the Gx1 processors.
Display modes supported by GX1 and SCx200 processors
- 640x480 @ 60, 72, 75, 85Hz , 8 and 16 Bpp
- 800x600 @ 56, 60, 72, 75, 85Hz , 8 and 16 Bpp
- 1024x768 @ 60, 70, 75, 85Hz , 8 and 16 Bpp
- 1280x1024 @ 60, 70, 75Hz, 8 Bpp
Modes supported only in Pyramid
- 1280x1024 @ 85Hz, 8 Bpp
- 1280x1024 @ 60, 75, 85Hz, 16 Bpp.
The Geode driver has support for 2 PAL ("PAL-768x576", "PAL-720x576")
and 2 NTSC("NTSC-640x480", "NTSC-720x480") TV Modes Apart from the
CRT Modes defined above.
The TV Modes works only in 16 BPP. So, while testing the TV Modes, the Display
should be set for 16 BPP.
TV MODES ARE SUPPORTED ONLY ON PLATFORMS WITH SC1200 AND SUPPORTED HARDWARE
LIKE CYGNUS.
The Geode Driver can also support DSTN, SSTN and TFT Panels. The Panels
have been tested on Centaurus and Dorado Platforms.
Pixel rotation supported giving the portait look of the Framebuffer
in clockwise or anti-clockwise direction.
DPMS supported for Display power management.
Direct Graphics Acceleration(DGA) supported
TV Overscan Supported.
Xfree 4.0.1 FBDev driver
XFree FBDev driver is a non-accelerated XFree graphics driver for National
hardware. It is completely dependent on the underlying NSC Kernel
frame buffer driver (KFB) to switch modes and rendering geometry.
This is one of the simplest forms of the graphics driver provided by Xfree.
Xfree FBDev driver dont support features like dga, Rotation, video, panel,
TV Overscan.
To understand the usage of various components of XFree86 4.0.1 driver look
into the "$/Engineering_Releases/dr
/packing_distribution.doc V0.0.2" in VSS "video" database. This document
explains the drivercomponents STB, Non STB and XFBDEv.And it gives the
interface XFree driver with the Kernel Framebuffer driver(KFB driver)
--------------------------
2. INSTALLATION INSTRUCTIONS
--------------------------
There are many significant changes to XFree86 reflected in the 4.0.1 release.
- To use XFree86 4.0, download the source from: http://www.xfree86.org/
or
you can get a copy from the VSS at
"\\video\engineering_relea
- If you have XFree v3.3.6 installed in your system. Before inflating the v4.01
*.bz files, rename the /usr/X11R6 directory as /usr/X11R6.336.
- Change directory to /usr/bin, "rm -rf X11"
- Change directory to /usr/lib, "rm -rf X11"
- Change directory to /usr/include, "rm -rf X11"
- Now extract the *.bz files in the directory desired.
- Pl. follow the build instructions for building the XServer.
- There is only one Xserver in 4.0: XFree86. It will load the modules/drivers
that it needs at run-time. These drivers are located at:
/usr/X11R6/lib/modules/dri
- Pl. use the XF86Config file supplied to you.
1. Copy XF86Config.geode to /etc/X11/XF86Config for both STB and non-STB
configurations.
2. Copy XF86Config.fbdev to /etc/X11/XF86Config for Xfree86 4.0.1 FBDev driver.
FBDev uses the resoultion set by the Framebuffer.
--------------------------
3.Understanding the Xserver
--------------------------
The Xserver manages client connections and responds on behalf of clients
to user interface events (mouse, keyboard input) and protocol requests
(graphics). It is divided into 4 major pieces:
- device independent layer (DIX): code shared among all implementations
- OS layer: code which is different between operating systems but shared
among all devices of an operating system
- device dependent layer (DDX): code which is potentially different between
operating systems and graphics devices
- extension interface: the standard way to add features to the X server
For more information on this, see the xc/doc directory.
--------------------------
4.BUILD INSTRUCTIONS
--------------------------
- These instructions are laid out based on the assumtion that you have a
Redhat 6.2 installation. You may have to skip few of the steps other
than Redhat installation.
- Build and install crlf utility. For more information look at readme.txt in
crlf provided.
- crlf on all the code provided. Read the crlf usage in the crlf/readme.txt.
- If you have XFree v3.3.6 installed in your system. Before inflating the v4.01
*.bz files, rename the /usr/X11R6 directory as /usr/X11R6.336.
- Change directory to /usr/bin, "rm -rf X11"
- Change directory to /usr/lib, "rm -rf X11"
- Change directory to /usr/include, "rm -rf X11"
- Now extract the *.bz files in the directory desired.
- After the 'xc' tree is created, copy the files under revision control into
their respective places in the 'xc' tree.
- move to xc/programs/Xserver/hw/xfr
- If you are building the Xserver for Set-Top-Box solution with "GAL" and
"Framebuffer". Rename the Imakefile.stb as Imakefile.
Build the Framebuffer and GAL for Set-Top-Box solution.
- If building for a standalone Xserver for
Tinclient or Webpad solution. Rename Imakefile.pad Imakefile.
- Pl. follow the bellow 2 steps for NON-STB SOLUTION ONLY.
1. Copy the contents of the Durango directory which is specified
in the release notes into
"/usr/X11R6/xc/programs/Xs
2. Copy the contents of the Panel library which is specified
in the release notes into
"/usr/X11R6/xc/programs/Xs
- There is only one Xserver in 4.0.1 XFree86. It will load the modules/drivers
that it needs at run-time. These drivers are located at:
/usr/X11R6/lib/modules/dri
- Frame buffer is must for SetTopBox Solution and XFree 4.0.1 FBDev driver.
- To Build the Frame buffer driver Pl. follow the Frame buffer install and
build instructions as per readme.txt.
- GAL Library(REQUIRED FOR SetTopBox Solution ONLY)
For the XServer to compile you require libgal.a. To build a GAL library Pl.
follow the GAL install and build instructions.
- To initiate a full build, switch to the '<install dir>/xc' directory.
Enter 'make World >& world.out'. This will start the build process.
If all of the configuration parameters are correct,
this step will only needed once.
- After Successful make, Enter 'make install' to install X11.
- switch to geode dir
"cd <install dir>/xc/programs/Xserver/h
- Execute "make install" from the geode directory. This builds only the
geode module.
- The X binaries are placed under "/usr/bin/X11" and make sure you have this
directory in your path.
- Now to setup the font direcories correctly "cd /usr/lib/X11/fonts/misc".
execute "mkfontdir" here to setup the font directories.
Configuring the Xserver
--------------------------
Working XF86Config file is attached and should be used.
Before configuring the Xserver, copy /etc/X11/XF86Config to XF86Config.bak.
A Geode mode specific XF86Config is supplied to install this copy the supplied
XF86Config.geode to /etc/X11/XF86Config.
Different Options in XF86Config (For sTB and Non STB solutions):
--------------------------
To enable H/W compression, Option "Compression".
Cursor option:
Cursor can be drawn either Hardware or Software.
1.To enable Software cursor, Uncomment the Option "SWcursor" and comment
the option "HWcursor".
2.To enable HW cursor, Uncomment the Option "HWcursor" and comment the
option "SWcursor".
Default HWcursor will be enabled.
DGA option:
1.To enable DGA, Uncomment the Option "xfree86-dga" and comment
the option "omit xfree86-dga".
2.To disable DGA, comment the Option "xfree86-dga" and uncomment
the option "omit xfree86-dga".
Default DGA will be selected.
DGA is disabled if TV Overscan is enabled.
CRT mode option:
OffScreen Memory option:
To use Offscreen FrameBuffer memory, Uncomment the Option "OffScreenMemory".
Default this option will be enabled.
CRT mode option:
Default Monitor Depth set to 16 bit.
Default crt modes are in the order "1280x1024","1024x768","80
and "640x480".
Driver selects the highest resolution supported by the hardware in the
above order.
If the selected hardware mode is not supported by the Monitor. The user
will get a blank screen or a garbage on the screen. If this happened
Comment the highest display mode (e.g "1280x1024") and test again.
Repeat this till Hardware CRT display mode and Monitor supported mode
compatible.
Note: If a TV mode option set and if it is a TV supported platform
the CRT modes will be ignored.
TV mode option:
To Enable 768x576 Pal Mode, In the XF86Config file,
Option "TV" "PAL-768x576" parameter should be set.
To Enable 704x576 Pal Mode, Option "TV" "PAL-704x576" parametershould be set.
For NTSC mode, Option "TV" "NTSC-640x480" or "NTSC-720x480" should be set.
Once the TV option selected the CRT mode options are ignored,
even the CRT mode option are set.
Flat Panel option:
To Enable the Panel Option,"Option FlatPanel" should be set.
To disable the panel, Option "FlatPanel" has to be commented out.
Panel h/w can be initialized in two ways.Initialization done by BIOS, or done
by the driver ONLY FOR NSC PLATFORMS.
To initialize the panel using BIOS set,the Option "Flatpanel" and
Option "FlatPanelInBios".If Bios doesn't support the panel, panel will be
disabled, only CRT will be enabled.
Use Option "Flatpanel" only in case of NSC platform.
If platform supports panel, panel will be enabled.
Make sure when Panel is enabled, only one resolution is supported.
We can't have Multiple resolutions.
When TV is enabled, Panel support is automatically disabled.
Rotation option:
To enable Framebuffer rotation clockwise, Option "Rotate" "CW" is used.
To enable Framebuffer rotation counter clockwise, Option "Rotate" "CCW"
is used.
The portrait mode operates slower for all functions.
In portrait mode Acceleration is turned off and co-ordinate transformation
also takes place.
All this is being done in software, which adds extra delay.
The user sees everything slower in portrait mode.
Drawing operations will be slow in non-accelerated driver.
Non-Accelerated driver is slow with respect to accelerated driver.
Tv Overscan option:
Tv Overscan will work on platforms like cygnus which support TV.
To enable TV Overscan, Option "TVOverscan" "xx:yy:ww:hh" is used.
In this option xx is the X-offset value
yy is the y-offset value
ww is the Width of the Screen
hh is the Height of the screen.
All the values should be >=0.
ww + xx <= resolution width
hh + yy <= resolution height
If any of the above conditions fails TVOverscan will be disabled.
DGA is disabled if TV Overscan is enabled.
In addition to the above options the Xfree86 4.0.1 driver supports the
options "ShadowFB",
"Overlay", "ColorKey" and "VideoKey".
- Run xinit or startx to launch the Xfree 4.0.1 driver.
Xfree 4.0.1 FBDev driver:
-------------------------
To build the Xfree 4.0.1 FBDev driver
- Build and install the FFrame buffer driver
which is specified in the release notes.
- Use the XF86Config.fbdev which is specified in the release notes.
- Run xinit or startx to launch the Xfree 4.0.1 driver.
--------------------------
7. UNIT TEST
--------------------------
Testing:
- The driver was tested on Centaurus, Dorado and Cygnus Platforms.
The TV modes are tested on Cygnus SC1200 Rev B board with a GX1 8.1 processor
and 64 Mbytes of RAM. XpressROM version v2.9.2 has been used to test this
version of driver.
- DSTN and TFT Panels have been tested on Centaurus and Dorado Platforms.
- Correct jumper settings has to be set on Centaurus and Dorado Platforms.
- For Dorado Platform:
fixed J61 jumper setings for flat panel - they are now:
J61 LCD Mode Selector Jumper
1-2 3-4 5-6 9-10 Type of LCD Panel
NS9211 NS9211 NS9211 NS9211
GPIO0 GPIO1 GPIO2 GPIO4
OFF OFF OFF OFF 800x600 16 Bit Color Dual STN
OFF OFF ON OFF 640x480 16 Bit Color Dual STN
OFF ON OFF OFF 1024x768 24 Bit Color Dual STN
OFF ON ON OFF 640x480 8 Bit Color Single STN
ON OFF OFF OFF 640x480 8 Bit Mono Dual STN
ON OFF ON OFF 1024x768 18 Bit Color TFT
ON ON OFF OFF 640x480 18 Bit Color TFT
ON ON ON OFF 800x600 18 Bit Color TFT
ON ON ON ON Flat panel disabled
- For Centaurus Platform:
fixed J14 jumper setings for flat panel - they are now:
J14 LCD Mode Selector Jumper
1-2 3-4 5-6 Type of LCD Panel
NS9211 NS9211 NS9211
GPIO0 GPIO1 GPIO2
OFF OFF OFF 800x600 16 Bit Color Dual STN
OFF OFF ON 640x480 16 Bit Color Dual STN
OFF ON OFF 1024x768 24 Bit Color Dual STN
OFF ON ON 640x480 8 Bit Color Single STN
ON OFF OFF 640x480 8 Bit Mono Dual STN
ON OFF ON 1024x768 18 Bit Color TFT
ON ON OFF 640x480 18 Bit Color TFT
ON ON ON 800x600 18 Bit Color TFT
- Run xinit or startx to launch the Xfree 4.0.1 driver.
- Run Xvtest application for Xv extensions.
- To test TV Overscan, Enable the Option "TVOverscan" "xx:yy:ww:hh"
in /etc/X11/XF86Config file.
--------------------------
8. VALIDATION NOTES
--------------------------
When the XServer is configured for portrait mode using Option Rotate, the
GNOME logout function will perform very slowly.
INFORMATION: Instead of using StartX to initialize XWindows, use Xinit, from
there run the window manager (ie KDE or GNOME). If using startx, you may need
to edit the xinit portion of the startx script to have xinit load a window
manager on startup. With RedHat 6.2, and XFree86 3.3.6, the path to the xinit
and startx commands is /usr/X11R6/bin. XFree86 4.0.1 stores these commands in
/usr/X11/bin, so necessary environment variables will also need to be updated.
--------------------------
9. REVISION HISTORY
--------------------------
Version 1.2.0. - (May 16th, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.2.0
GAL v1.2.0
Durango v2.41.02
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
- Driver tested on the Durango Version 2.41.02.
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
- geode_driver.c
- durango.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
Version 1.1.0b. - (April 18th, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.7b
GAL v1.1.4
Durango v2.41.01
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
- Driver tested on the Durango Version 2.41.01.
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
- None
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
Version 1.1.0a. - (April 16th, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.7a
GAL v1.1.4
Durango v2.35.01
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
- Driver tested on the Linux kernel Version 2.4.17.
- It supports all the functionality of the Driver v1.1.0 on the Kernel V2.4.17
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
- None
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
Version 1.1.0. - (Jan 20, 2002)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.6
GAL v1.1.4
Durango v2.35.01
Panel v1.2.7
__________________________
FUNCTIONAL CHANGES
--------------------------
--------------------------
DEFECTS CORRECTED
--------------------------
- Fixed the behavior of the TV Overscan on Non TV platforms.
- #81.23 Panel selection option in XF86Config file.
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.9 - (Dec 28, 2001)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.5
GAL v1.1.3
Durango v2.35.01
Panel v1.2.6
__________________________
FUNCTIONAL CHANGES
--------------------------
- Added TV Overscan support.
--------------------------
DEFECTS CORRECTED
--------------------------
- Panel selection problem was fixed.
- #81.15 Framebuffer and XFree readme.txt confusing.
--------------------------
FILE CHANGES
--------------------------
geode.h
geode_driver.c
geode_accel.c
geode_cursor.c
geode_video.c
XF86Config.geode
XF86Config.fbdev
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.8 - (Nov 8, 2001)
Dependencies
crlf v1.0.1o
Framebuffer driver v1.1.4
GAL v1.1.3
Durango v2.35.01
Panel v1.2.5
__________________________
FUNCTIONAL CHANGES
--------------------------
- Added panel initialization either from BIOS or depending on NSC platform.
- Compression is provided as an option.
--------------------------
DEFECTS CORRECTED
--------------------------
-
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode.h
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.7 - (June 20, 2001)
Dependencies
crlf v1.0.0
Framebuffer driver v1.1.3
GAL v1.1.2
Durango v2.31.0
Panel v1.2.3
__________________________
FUNCTIONAL CHANGES
--------------------------
- Use gfx_set_display_bpp to set the BPP in both DP and GP.
--------------------------
DEFECTS CORRECTED
--------------------------
- 111.3 XVtest documentation does not match performance
- 81.5 Framebuffer and XFree readme.txt confusing
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.6 - (June 5, 2001)
Dependencies
crlf v1.0.0
Framebuffer driver v1.1.2
GAL v1.1.2
Durango v2.31.0
Panel v1.2.3
__________________________
FUNCTIONAL CHANGES
--------------------------
- Added acceleration for monochrome bitmap.
- Save and restore the complete h/w(tv, panel, CRT, compression, cursor)
--------------------------
DEFECTS CORRECTED
--------------------------
- 81.16
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode.h
geode_accel.c
geode_cursor.c
geode_video.c
Imakefile
durango.c
panel.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.5 - (March 15, 2001)
Dependencies
crlf v1.0.0
Framebuffer driver v1.1.0
GAL v1.1.0
Durango v2.26
Panel v1.2.0
__________________________
FUNCTIONAL CHANGES
--------------------------
-Modified the code to operate independently also of STB arch..
--------------------------
DEFECTS CORRECTED
--------------------------
- 81.16
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode.h
geode_accel.c
geode_cursor.c
geode_video.c
Imakefile
durango.c
panel.c
--------------------------
KNOWN ERRATA
--------------------------
- None
--------------------------
version 1.0.4 - (Feburary 3, 2001)
Dependencies
Framebuffer driver 1.09
GAL 1.0.5
__________________________
FUNCTIONAL CHANGES
--------------------------
-Added NTSC and PAL TV support.
-Added DSTN and TFT Flat Panel Support.
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
--------------------------
KNOWN ERRATA
--------------------------
- If the X comes up with Panel enabled, later even if you disable panel support
cursor panning still takes place.
--------------------------
--------------------------
version 1.0.3 - (January 08, 2001)
Dependencies
Framebuffer driver 1.09
GAL 1.0.4
__________________________
FUNCTIONAL CHANGES
--------------------------
-Added compression and dynamicaly position cursor offset.
-Enabled 1280x1024 16BPP mode.
-Added dynamic setting of Max suppoorted pixel clock.
-Added DGA support.
-Added ShadowFB and Rotataion support Clockwise or Counter-Clockwise.
-Added Panel Option support. Modified the GAL interface and removed galapi.h
and all the GAL protocols and struct definition moved to one single header
file galproto.h
-Added Panel parameters to the driver. Handle the Panel option appropriately
and fill the panel structure.
-Added DPMS support for geode driver. Currently only enable and disable are
supported. StandBy and suspend need to be done.
-Added Panel parameters to the driver. Handle the Panel option appropriately
and fill the panel structure.
-Panel Options added To trigger panel support enable
Option "Panel" "paneltype"
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
geode_driver.c
geode_dga.c
geode.h
XF86Config
galproto.h
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
--------------------------
Version 1.0.2 (November 2, 2000) Companion Framebuffer driver 1.07
and GAL version 1.0.3
__________________________
FUNCTIONAL CHANGES
--------------------------
- Graphics modeset now work from text modes too
- Added a new GAL stub to compile GAL with XFree driver as a module
- Xfree 401 has its own libc implementation which has to be used for
module support
- Added support for XFree 4.0.1.
- Restructured galproto.h to be independent of galapi.h
- Added (set/get)displaytiming and setpalette APIs
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
Version 1.0.1 (October 20, 2000) Companion Framebuffer driver 1.06
and GAL version 1.0.2
__________________________
FUNCTIONAL CHANGES
--------------------------
- Switched to using GAL
- Support for GAL 1.0.2
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
__________________________
Version 1.0.0 (September 22, 2000)
__________________________
FUNCTIONAL CHANGES
--------------------------
Initial version - supports Gxm, SC1200
--------------------------
DEFECTS CORRECTED
--------------------------
- None
--------------------------
FILE CHANGES
--------------------------
--------------------------
KNOWN ERRATA
--------------------------
- None listed
--------------------------
OK, this is instructions for replacing XFree 3.3.6 on a RedHat 6.2 systen with XFree 4.0.1 (modified to include the geode driver).
This doesn't sit too well with Mdk8.0 (IIRC:-). I'll have to "mull this over" and check exactly what is included where in 8.0, before proposing a set of actions that should provide you with a working driver.
"I'll be back";-)
-- Glenn
This doesn't sit too well with Mdk8.0 (IIRC:-). I'll have to "mull this over" and check exactly what is included where in 8.0, before proposing a set of actions that should provide you with a working driver.
"I'll be back";-)
-- Glenn
Right, Mandrake 8.0 installs XFree 4.0.3 or 3.3.6 (The "skeleton" is 4.0.3, but if /etc/X11/X is symlinked to /usr/X11R6/bin/XF86_<somet
If you follow the instructions "to the letter", you will probably revert your system to using 4.0.1, and in the process render large parts of the rpm database invalid. Not a good thing:-).
If I understand what I can find on the web correctly, and what you've said so far, the graphics on this system is based on the National Semiconductors GX1 (geode), with the 5530 "Graphics companion". Does it have the 9211 "Flat Panel thing" too?
This (the geode GX1) seem to have started life as the "Cyrix MediaGX combined CPU/Graphics chip", so chances are you could use the 4.0.3 "cyrix" driver, or the "mediagx" of 3.3.6's XF86_SVGA server. At least worth exploring...
-- Glenn
If you follow the instructions "to the letter", you will probably revert your system to using 4.0.1, and in the process render large parts of the rpm database invalid. Not a good thing:-).
If I understand what I can find on the web correctly, and what you've said so far, the graphics on this system is based on the National Semiconductors GX1 (geode), with the 5530 "Graphics companion". Does it have the 9211 "Flat Panel thing" too?
This (the geode GX1) seem to have started life as the "Cyrix MediaGX combined CPU/Graphics chip", so chances are you could use the 4.0.3 "cyrix" driver, or the "mediagx" of 3.3.6's XF86_SVGA server. At least worth exploring...
-- Glenn
There is some "interresting" interpretation "leeway" in the instructions... the following
-------
- Pl. use the XF86Config file supplied to you.
1. Copy XF86Config.geode to /etc/X11/XF86Config for both STB and non-STB
configurations.
2. Copy XF86Config.fbdev to /etc/X11/XF86Config for Xfree86 4.0.1 FBDev driver.
FBDev uses the resoultion set by the Framebuffer.
----------
I presume these are the "multiple copies" that confounds you?
Don't worry too much: If you are using a framebuffer device (provided by the linux kernel), you should do #2, in all other cases you should do #1.
If you use LILO to boot, the presense of "vga=<number>" or "vga=ask" indicates that a kernel driven framebuffer might be in use. If so, you might opt to let X use a very simple device driver to draw directly on this framebuffer, instead of having X handle the device directly.
Anyway, I still think you should try out the mediagx drivers (according to the 4.0.3 drivers README (/usr/X11R6/lib/X11/doc/RE
What exactly did the Advantech people send to you? A source tar-ball?
-- Glenn
-------
- Pl. use the XF86Config file supplied to you.
1. Copy XF86Config.geode to /etc/X11/XF86Config for both STB and non-STB
configurations.
2. Copy XF86Config.fbdev to /etc/X11/XF86Config for Xfree86 4.0.1 FBDev driver.
FBDev uses the resoultion set by the Framebuffer.
----------
I presume these are the "multiple copies" that confounds you?
Don't worry too much: If you are using a framebuffer device (provided by the linux kernel), you should do #2, in all other cases you should do #1.
If you use LILO to boot, the presense of "vga=<number>" or "vga=ask" indicates that a kernel driven framebuffer might be in use. If so, you might opt to let X use a very simple device driver to draw directly on this framebuffer, instead of having X handle the device directly.
Anyway, I still think you should try out the mediagx drivers (according to the 4.0.3 drivers README (/usr/X11R6/lib/X11/doc/RE
What exactly did the Advantech people send to you? A source tar-ball?
-- Glenn
ASKER
hi,
first of all thanks for your effort.
advantech engineers sent me a source tarball.
currently i also have a problem with lilo.()
'using a framebuffer device': isn't it something i can choose?
i can install xfree86-fb or xfree86-svga? right?
i dont know exactly what each refers to but i have read something like this.:)
regards.
first of all thanks for your effort.
advantech engineers sent me a source tarball.
currently i also have a problem with lilo.()
'using a framebuffer device': isn't it something i can choose?
i can install xfree86-fb or xfree86-svga? right?
i dont know exactly what each refers to but i have read something like this.:)
regards.
You can install it, but:
xfree86-svga == version 3.3.6 Standalone X server which takes care of the graphics HW by itself.
xfree86-fb == version 3.3.6 "Standalone" X server which needs a framebuffer device to be provided by the Linux kernel.
Version 4.0.3 uses a "generic" server binary (/usr/X11R6/bin/XFree86) which loads modules for taking care of the hardware specific details, so which module will be used is controlled by the content of the /etc/X11/XF86Config-4 file (you can have several Device sections, with different Identifier & Driver, and choose one Device in the Screen section). Of course 4.0.3 also support a frame buffer device, as well as a generic "vesa" Driver.
-- Glenn
xfree86-svga == version 3.3.6 Standalone X server which takes care of the graphics HW by itself.
xfree86-fb == version 3.3.6 "Standalone" X server which needs a framebuffer device to be provided by the Linux kernel.
Version 4.0.3 uses a "generic" server binary (/usr/X11R6/bin/XFree86) which loads modules for taking care of the hardware specific details, so which module will be used is controlled by the content of the /etc/X11/XF86Config-4 file (you can have several Device sections, with different Identifier & Driver, and choose one Device in the Screen section). Of course 4.0.3 also support a frame buffer device, as well as a generic "vesa" Driver.
-- Glenn
What I would try doing is:
1. install XFree86-server-4.0.3 package (this installs the XFree86 server, and all the "standard driver" modules (into /usr/X11R6/lib/modules/dri
1a. try the "cyrix" driver.
2. unpack the sorce "somewhere". Build it more or less as instructed, but not follow any of the "destructive" moves/removes/copies, and _not_ performing any install (that is, not typing "make install").
3. copy the geode driver to /usr/X11R6/lib/modules (and anything that it might depend on to the respective places they need to go).
Is it only the driver sources, or does it seem to be a complete "X source distro"?
It's a bit awkward to give instructions, not having seen the code... If it's not too huge, could you mail it to glennsteen@netscape.net?
-- Glenn
1. install XFree86-server-4.0.3 package (this installs the XFree86 server, and all the "standard driver" modules (into /usr/X11R6/lib/modules/dri
1a. try the "cyrix" driver.
2. unpack the sorce "somewhere". Build it more or less as instructed, but not follow any of the "destructive" moves/removes/copies, and _not_ performing any install (that is, not typing "make install").
3. copy the geode driver to /usr/X11R6/lib/modules (and anything that it might depend on to the respective places they need to go).
Is it only the driver sources, or does it seem to be a complete "X source distro"?
It's a bit awkward to give instructions, not having seen the code... If it's not too huge, could you mail it to glennsteen@netscape.net?
-- Glenn
Oh BTW, what's up with LILO?
I might be able to help there too (I've "debugged" a lot of malfunctioning lilo configurations over the years).
-- Glenn
I might be able to help there too (I've "debugged" a lot of malfunctioning lilo configurations over the years).
-- Glenn
ASKER
is 589 KByte too huge for you?
ASKER
the problem with lilo is:
it says LI and hangs
i have read several documents about.
first of all the BIOS is old and has no LBA support.
i have deavtivated LBA in LILO but it did not work.
my bootable partition is 2048 cylinders long, i reduced the size of that partition but it did not work, either.
may there be a problem with the MBR of the Harddisk?
it says LI and hangs
i have read several documents about.
first of all the BIOS is old and has no LBA support.
i have deavtivated LBA in LILO but it did not work.
my bootable partition is 2048 cylinders long, i reduced the size of that partition but it did not work, either.
may there be a problem with the MBR of the Harddisk?
589 KiB is quite acceptable.
No, there is no problem with the MBR, since if that couldn't be "found" by the BIOS, you'd end up with a blank screen (not even LI).
The individual characters L-I-L-O correspond to different steps in the LILO boot process, so this actually confers some knowledge on what is (most likely) to be wrong.
Some times when LILO stops "in the middle of everything" it emitts an errorcode (often repeated so fast, and infinitely, so that it can be hard to determine just _where_ (between which letters) the error occured). This code can then help further in diagnosing the problem.
In your case, the first stage loader (which resider in the 512 byte "large" MBR) has been found and executed, and it is trying to load and execute the (much larger) second stage loader. It fails miserably.
This is either because of a "geometry missmatch" (That is: the BIOS and LILO don't agree on the interpretation of C/H/S), or the second stage loader might reside above the 1024 cylinder limit. If the system lacks LBA completely, the 1024 limit is really low (below approx 528 MiB, IIRC).
The BIOS probably have *some* sort of LBA support (if the mobo is older than 1998, it'll probably be "plain" LBA, not LBA32). "Plain" LBA is "linear" option in "LILO-speak", and LBA32 is (of course) lba32.
So, here's what you need do:
During install, make a small (50 MiB) partition at the very beginning of the drive, with "/boot" as mountpoint. The rest you can partition any way you like, because the kernel will not use geometric adressing, and wont use the BIOS at all for disk access.
Ensure that the "LBAness" is _the same_ both in the BIOS, and in the LILO configuration (no mention of linear or lba32). You might need to be in "expert" mode to see that option during the installation of the bootloader, it's been a while since I installed a Mdk8.0 so I don't really remember.
With those two steps, you should be able to boot directly via MBR. I'd guess the first (the separate /boot) to be the most important in your case.
Did you make a boot-floppy? Does that boot?
-- Glenn
No, there is no problem with the MBR, since if that couldn't be "found" by the BIOS, you'd end up with a blank screen (not even LI).
The individual characters L-I-L-O correspond to different steps in the LILO boot process, so this actually confers some knowledge on what is (most likely) to be wrong.
Some times when LILO stops "in the middle of everything" it emitts an errorcode (often repeated so fast, and infinitely, so that it can be hard to determine just _where_ (between which letters) the error occured). This code can then help further in diagnosing the problem.
In your case, the first stage loader (which resider in the 512 byte "large" MBR) has been found and executed, and it is trying to load and execute the (much larger) second stage loader. It fails miserably.
This is either because of a "geometry missmatch" (That is: the BIOS and LILO don't agree on the interpretation of C/H/S), or the second stage loader might reside above the 1024 cylinder limit. If the system lacks LBA completely, the 1024 limit is really low (below approx 528 MiB, IIRC).
The BIOS probably have *some* sort of LBA support (if the mobo is older than 1998, it'll probably be "plain" LBA, not LBA32). "Plain" LBA is "linear" option in "LILO-speak", and LBA32 is (of course) lba32.
So, here's what you need do:
During install, make a small (50 MiB) partition at the very beginning of the drive, with "/boot" as mountpoint. The rest you can partition any way you like, because the kernel will not use geometric adressing, and wont use the BIOS at all for disk access.
Ensure that the "LBAness" is _the same_ both in the BIOS, and in the LILO configuration (no mention of linear or lba32). You might need to be in "expert" mode to see that option during the installation of the bootloader, it's been a while since I installed a Mdk8.0 so I don't really remember.
With those two steps, you should be able to boot directly via MBR. I'd guess the first (the separate /boot) to be the most important in your case.
Did you make a boot-floppy? Does that boot?
-- Glenn
ASKER
hi,
i dont have LILO problem any more.
for the xwindows problem, installed redhat7.2 as i saw some mails in the mailing lists that 7.2 can easily detect mycard.
during installation it recognized the card.(cool:) )
but i think i have a problem in the configuration as when i use startx it says:
a few things that i cannot catch and:
(--)SVGA: VSA1 detected
(--)SVGA: chipset: mediagx
(--)SVGA: videoram:2048k
(--)SVGA: Option "hw_cursor"
(--)SVGA: Using 16 bpp, Depth 16, Color weight:565
(--)SVGA: Maximum allowed dot-clock: 135.000 MHz
(--)SVGA: There is no mode definition named "1024*768"
Fatal server error:
No valid modes found
bla bla bla
now; how can i solve this issue?
the card is supposed to support 1024*768 resolution.
but it seems that this resolution's mode name is something different.:)
regards
i dont have LILO problem any more.
for the xwindows problem, installed redhat7.2 as i saw some mails in the mailing lists that 7.2 can easily detect mycard.
during installation it recognized the card.(cool:) )
but i think i have a problem in the configuration as when i use startx it says:
a few things that i cannot catch and:
(--)SVGA: VSA1 detected
(--)SVGA: chipset: mediagx
(--)SVGA: videoram:2048k
(--)SVGA: Option "hw_cursor"
(--)SVGA: Using 16 bpp, Depth 16, Color weight:565
(--)SVGA: Maximum allowed dot-clock: 135.000 MHz
(--)SVGA: There is no mode definition named "1024*768"
Fatal server error:
No valid modes found
bla bla bla
now; how can i solve this issue?
the card is supposed to support 1024*768 resolution.
but it seems that this resolution's mode name is something different.:)
regards
This new problem is simply a slight typo.
1024 * 768 should be expressed as the string "1024x768".
It seems to me like (please correct me if I'm wrong... no, I'm not:-) RH7.2 uses the "user safe" (according to the 4.x mediagx readme) 3.3.6 implementation.
Where 4.X would "autogenerate" ModeLines for you to use (it can still use a "handcrafted" ModeLine;), 3.3.6 needs to have them specified in the Monitor section of /etc/X11/XF86Config.
Typical ModeLine might look something like:
# 75 Hz modes
ModeLine "640x480" 31.5 640 656 720 840 480 481 484 500 -hsync -vsync
ModeLine "800x600" 49.5 800 816 896 1056 600 601 604 625 +hsync -vsync
ModeLine "1024x768" 78.8 1024 1040 1136 1312 768 769 772 800 +hsync -vsync
Note the string just after the keyword ModeLine. That is the string you have to specify in the Modes line of the relevant Display subsection of the Screen section. You can specify several modes as in:
Modes "1024x768" "800x600" "640x480"
Unless you specify a Virtual size, the virtual reolution will be set to the largest mode specified.
You can cycle through the specified modes with <Ctrl>-<Alt>-<KeyPad+> or <Ctrl>-<Alt>-<KeyPad->. This is a very useful feature when determining what modes actually work with a specific setup.
In 3.3.6 the "<string>" can be any string, as long as there is a matching ModeLine identifier, which can be very neat when trying several modes with the same resolution (X will opt for the highest possible refreshrate, which isn't always the best for your combination of X server, monitor and graphics adapter).
Note also that the failure of Mdk8 to autodetect your hardware doesn't mean it wouldn't support your card (in fact it would, exactly as RH7.2). See it as a deficiency in XFDrake vis-a-vis Xconfigurator (the "friendly" X configuration aides).
-- Glenn
1024 * 768 should be expressed as the string "1024x768".
It seems to me like (please correct me if I'm wrong... no, I'm not:-) RH7.2 uses the "user safe" (according to the 4.x mediagx readme) 3.3.6 implementation.
Where 4.X would "autogenerate" ModeLines for you to use (it can still use a "handcrafted" ModeLine;), 3.3.6 needs to have them specified in the Monitor section of /etc/X11/XF86Config.
Typical ModeLine might look something like:
# 75 Hz modes
ModeLine "640x480" 31.5 640 656 720 840 480 481 484 500 -hsync -vsync
ModeLine "800x600" 49.5 800 816 896 1056 600 601 604 625 +hsync -vsync
ModeLine "1024x768" 78.8 1024 1040 1136 1312 768 769 772 800 +hsync -vsync
Note the string just after the keyword ModeLine. That is the string you have to specify in the Modes line of the relevant Display subsection of the Screen section. You can specify several modes as in:
Modes "1024x768" "800x600" "640x480"
Unless you specify a Virtual size, the virtual reolution will be set to the largest mode specified.
You can cycle through the specified modes with <Ctrl>-<Alt>-<KeyPad+> or <Ctrl>-<Alt>-<KeyPad->. This is a very useful feature when determining what modes actually work with a specific setup.
In 3.3.6 the "<string>" can be any string, as long as there is a matching ModeLine identifier, which can be very neat when trying several modes with the same resolution (X will opt for the highest possible refreshrate, which isn't always the best for your combination of X server, monitor and graphics adapter).
Note also that the failure of Mdk8 to autodetect your hardware doesn't mean it wouldn't support your card (in fact it would, exactly as RH7.2). See it as a deficiency in XFDrake vis-a-vis Xconfigurator (the "friendly" X configuration aides).
-- Glenn
I've had a look at the source you sent, and I'm not surprised you got a bit ... confused by it.
Seems the file is slightly corrupt, since the ungzipping errors out. Perhaps harmless, but nevertheless...
They assume you would download the source to XFree86 version 4.0.1, and unpack this ...unprintable... on top of that.
They seem to be a gang of seriously confused windoze developers, the ones who have hacked this up (I don't know if you've noticed, but there is a directory "\" in every subdirectory, and all the files are line terminated by CR/LF... sigh).
Furthermore, they seem to assume a fixed absolute hierarchy... "file so-and-so _has_ to be at /a/fixed/path), which is plain stupid. DoubleSigh.
Sure, this will probably enable all sorts of glorious extensions and accelerations, but if you don't need 'em, it's probably best to stick with a "standard" mediagx driver.
-- Glenn
Seems the file is slightly corrupt, since the ungzipping errors out. Perhaps harmless, but nevertheless...
They assume you would download the source to XFree86 version 4.0.1, and unpack this ...unprintable... on top of that.
They seem to be a gang of seriously confused windoze developers, the ones who have hacked this up (I don't know if you've noticed, but there is a directory "\" in every subdirectory, and all the files are line terminated by CR/LF... sigh).
Furthermore, they seem to assume a fixed absolute hierarchy... "file so-and-so _has_ to be at /a/fixed/path), which is plain stupid. DoubleSigh.
Sure, this will probably enable all sorts of glorious extensions and accelerations, but if you don't need 'em, it's probably best to stick with a "standard" mediagx driver.
-- Glenn
ASKER
sorry for the mistake;
when i wrote 1024*768, i meant 1024x768.
when i look at XF86Config, i can see a mode "1024x768":
# **************************
# Screen section
# **************************
# The kernel framebuffer server
Section "Screen"
Driver "fbdev"
Device "Generic VGA Card"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
Subsection "Display"
# Depth 16
Depth 16
Modes "default"
EndSubsection
EndSection
# The 16-color VGA server
Section "Screen"
Driver "vga16"
Device "Generic VGA Card"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
Subsection "Display"
Modes "640x480" "800x600"
ViewPort 0 0
EndSubsection
EndSection
# The Mono server
Section "Screen"
Driver "vga2"
Device "Generic VGA Card"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
Subsection "Display"
Modes "640x480" "800x600"
ViewPort 0 0
EndSubsection
EndSection
# The svga server
Section "Screen"
Driver "svga"
Device "Cyrix MediaGX"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
DefaultColorDepth 8
Subsection "Display"
Depth 16
Modes "1024x768"
ViewPort 0 0
EndSubsection
EndSection
# The accel server
Section "Screen"
Driver "accel"
Device "Cyrix MediaGX"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
DefaultColorDepth 8
Subsection "Display"
Depth 16
Modes "1024x768"
ViewPort 0 0
EndSubsection
EndSection
what is wrong then?
regards.
when i wrote 1024*768, i meant 1024x768.
when i look at XF86Config, i can see a mode "1024x768":
# **************************
# Screen section
# **************************
# The kernel framebuffer server
Section "Screen"
Driver "fbdev"
Device "Generic VGA Card"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
Subsection "Display"
# Depth 16
Depth 16
Modes "default"
EndSubsection
EndSection
# The 16-color VGA server
Section "Screen"
Driver "vga16"
Device "Generic VGA Card"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
Subsection "Display"
Modes "640x480" "800x600"
ViewPort 0 0
EndSubsection
EndSection
# The Mono server
Section "Screen"
Driver "vga2"
Device "Generic VGA Card"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
Subsection "Display"
Modes "640x480" "800x600"
ViewPort 0 0
EndSubsection
EndSection
# The svga server
Section "Screen"
Driver "svga"
Device "Cyrix MediaGX"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
DefaultColorDepth 8
Subsection "Display"
Depth 16
Modes "1024x768"
ViewPort 0 0
EndSubsection
EndSection
# The accel server
Section "Screen"
Driver "accel"
Device "Cyrix MediaGX"
Monitor "Generic Standard VGA, 640x480 @ 60 Hz"
DefaultColorDepth 8
Subsection "Display"
Depth 16
Modes "1024x768"
ViewPort 0 0
EndSubsection
EndSection
what is wrong then?
regards.
ASKER
also it takes too long to start xfs. as i set to start with initlevel5, it is tried to start.
You have only specified one mode, so if (for some reason, such as the monitor "refreshrates" being too limited, or perhaps the driver doesn't support the combination of resolution/colordepth)) all the ModeLines for that particular resolution gets "auto-deleted" by the server, X wont start... so, a Modes line with more modes ("1024x768" "800x600" "640x480") makes it more probable X will find a ModeLine it can "grok".
The ModeLines are defined in the Monitor section (of which you can have several, but there usually only is one monitor, so...). As I said, 3.3.6 needs to have these specified, so you'll have to check that there is a "ModeLine colection" there.
If the server is deleting "out of range ModeLines", the relevant "error report" would be printed just prior to the error you have reported.
Take a peek at the monitor section in the XF86Config example you got from advantech, also look at how they use the multitude of modelines in the Screen->Display section.
You can copy modelines and modes specifications to your XF86Config... should work better:-)
-- Glenn
The ModeLines are defined in the Monitor section (of which you can have several, but there usually only is one monitor, so...). As I said, 3.3.6 needs to have these specified, so you'll have to check that there is a "ModeLine colection" there.
If the server is deleting "out of range ModeLines", the relevant "error report" would be printed just prior to the error you have reported.
Take a peek at the monitor section in the XF86Config example you got from advantech, also look at how they use the multitude of modelines in the Screen->Display section.
You can copy modelines and modes specifications to your XF86Config... should work better:-)
-- Glenn
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
hi gns,
i have solved my problems with some little tricks. but it was a very good feeling to know that someone is right there to help me during my problem. so i give you all of the points.
also i wil greatly appreciate if you can give some brief descriptions on xserver and lilo.
where is the xclient, server, DISPLAY environment variable, font server? bla bla bla
with kind regards.
byz.
i have solved my problems with some little tricks. but it was a very good feeling to know that someone is right there to help me during my problem. so i give you all of the points.
also i wil greatly appreciate if you can give some brief descriptions on xserver and lilo.
where is the xclient, server, DISPLAY environment variable, font server? bla bla bla
with kind regards.
byz.
Sorry it has taken me a while to get back to you, but I've been down with the flu since last week...
I'm glad you've found my mumblings helpful... So let's mumble onward:
What do you need to know? Be specific, and I'll try to emulate that:-).
One can genearally say that the X server is responsible for rendering graphics to one or more screens, nothing else. Understanding this limitation, and that it is by design, helps a lot when grappling with all the separate parts that make up the X windows environment such as display managers (that handle "login screens" etc), session managers (that try to keep a grip on which applications should run in which session etc), window managers (that decorate windows, place them on the screen etc) and the applications. Desktop environmants like KDE and GNOME try to make all these parts coherent as to look, feel and general behaviour, but since one usually have a lot of programs from deffering environments, and a whole army of "graphics toolkits" that differ slightly in look-n-feel, many find the end result to be rather confusing... I myself find it refreshing:-).
Lilo (the LInux LOader, an operating system bootloader) only have ramafications on the X server when a) you have specified a SVGA mode in lilo (example: vga=788 gives a framebuffer of resolution 800x600 @ 60Hz, which is pretty OK for a lowbudget flat panel) and b) use the "FBdev" Device in the X server configuration (XF86Config).
Now, as to the rest...
The X Font Server (xfs) is a rather neat "abstraction", where the job of keeping track of fonts, and rendering them in a way useable to the X server is delegated to a separate process. The X server can handle PCF (Portable Compiled Format) font files directly, but this is just bitmapped (ugly) fonts. Modern xfs can handle a rich set of font formats, including postscript (Adobe Type1) font and TTF fonts, which apart from being better looking, can be scaled, and there is a wealth of (free) font sources. The configuration of fonts, and building of "fonts.dir" files are a separate chapter, but you'll find the man xfs config file at /usr/X11R6/lib/X11/fs/conf
As you say, the DISPLAY variable is an environment variable. In bash you can set it with:
export DISPLAY=:0<Enter>
The "anatomy" of the variable is: <hostname-or-IPaddress>:<d
Lets imagine a machine named hosta, with IP address 192.168.0.1 and with a dual-head (two monitors attached) setup. The following two are then equivalent:
export DISPLAY=hosta:0
export DISPLAY=192.168.0.1:0.0
and will display any subsequent X application on the "first" monitor (usually the one on the left;) attached to hosta, while
export DISPLAY=hosta:0.1
would make them display on the second screen (usually the one on the right).
There can sometimes be several X servers running on a system (even "managing" the same graphics adaptor). In this case
export DISPLAY=hosta:1
would mean "display on the second X server running on hosta".
Most X applications (that are part of the XFree86 installation. The rest (browsers, wordprocessors etc etc live anywhere they please:-) as well as the server binaries "live" in the /usr/X11R6 directory. In the bin subdirectory you'll have applications and servers, in the lib subdirectory you'll have shared object libraries etc etc.
Is the reference to xclient meant as a reference to the $HOME/.Xclients config file (can be used to force a certain session/applicationset upon the user (analoguous to $HOME/.xinitrc))?
As you see, I'm not that precise in my guesses as to what you really want to know, so... be more specific:-).
-- Glenn
I'm glad you've found my mumblings helpful... So let's mumble onward:
What do you need to know? Be specific, and I'll try to emulate that:-).
One can genearally say that the X server is responsible for rendering graphics to one or more screens, nothing else. Understanding this limitation, and that it is by design, helps a lot when grappling with all the separate parts that make up the X windows environment such as display managers (that handle "login screens" etc), session managers (that try to keep a grip on which applications should run in which session etc), window managers (that decorate windows, place them on the screen etc) and the applications. Desktop environmants like KDE and GNOME try to make all these parts coherent as to look, feel and general behaviour, but since one usually have a lot of programs from deffering environments, and a whole army of "graphics toolkits" that differ slightly in look-n-feel, many find the end result to be rather confusing... I myself find it refreshing:-).
Lilo (the LInux LOader, an operating system bootloader) only have ramafications on the X server when a) you have specified a SVGA mode in lilo (example: vga=788 gives a framebuffer of resolution 800x600 @ 60Hz, which is pretty OK for a lowbudget flat panel) and b) use the "FBdev" Device in the X server configuration (XF86Config).
Now, as to the rest...
The X Font Server (xfs) is a rather neat "abstraction", where the job of keeping track of fonts, and rendering them in a way useable to the X server is delegated to a separate process. The X server can handle PCF (Portable Compiled Format) font files directly, but this is just bitmapped (ugly) fonts. Modern xfs can handle a rich set of font formats, including postscript (Adobe Type1) font and TTF fonts, which apart from being better looking, can be scaled, and there is a wealth of (free) font sources. The configuration of fonts, and building of "fonts.dir" files are a separate chapter, but you'll find the man xfs config file at /usr/X11R6/lib/X11/fs/conf
As you say, the DISPLAY variable is an environment variable. In bash you can set it with:
export DISPLAY=:0<Enter>
The "anatomy" of the variable is: <hostname-or-IPaddress>:<d
Lets imagine a machine named hosta, with IP address 192.168.0.1 and with a dual-head (two monitors attached) setup. The following two are then equivalent:
export DISPLAY=hosta:0
export DISPLAY=192.168.0.1:0.0
and will display any subsequent X application on the "first" monitor (usually the one on the left;) attached to hosta, while
export DISPLAY=hosta:0.1
would make them display on the second screen (usually the one on the right).
There can sometimes be several X servers running on a system (even "managing" the same graphics adaptor). In this case
export DISPLAY=hosta:1
would mean "display on the second X server running on hosta".
Most X applications (that are part of the XFree86 installation. The rest (browsers, wordprocessors etc etc live anywhere they please:-) as well as the server binaries "live" in the /usr/X11R6 directory. In the bin subdirectory you'll have applications and servers, in the lib subdirectory you'll have shared object libraries etc etc.
Is the reference to xclient meant as a reference to the $HOME/.Xclients config file (can be used to force a certain session/applicationset upon the user (analoguous to $HOME/.xinitrc))?
As you see, I'm not that precise in my guesses as to what you really want to know, so... be more specific:-).
-- Glenn
ASKER
i will have a question on xserver.
i have an embedded pc and an IBM monitor attached to it.
i run xconfigurator and select the monitor as custom.
then give the refresh rate ranges and then select all of the available resolution and bpp options.
then it says taht it will test and it hangs.:((
when i restart the machine, i type startx. it says:
SVGA: Mode "1024x768" needs hsync freq of 48.36 kHz. deleted.
And many other lines like this for the sam and the other resolution options.
the hsyns freq is one in the range i state for the monitor.
i am really stuck.
do you have any ideas?
thanks in advance.
best regards.
i have an embedded pc and an IBM monitor attached to it.
i run xconfigurator and select the monitor as custom.
then give the refresh rate ranges and then select all of the available resolution and bpp options.
then it says taht it will test and it hangs.:((
when i restart the machine, i type startx. it says:
SVGA: Mode "1024x768" needs hsync freq of 48.36 kHz. deleted.
And many other lines like this for the sam and the other resolution options.
the hsyns freq is one in the range i state for the monitor.
i am really stuck.
do you have any ideas?
thanks in advance.
best regards.
ASKER
hi,
i solved my problem with the following link.:))
http://www.larwe.com/technical/geode_linux.html
i cannot believe it but it happened.
thanks for all of your help.
i solved my problem with the following link.:))
http://www.larwe.com/technical/geode_linux.html
i cannot believe it but it happened.
thanks for all of your help.
Marvelous!
That 5530 "odd" bug would have been virtually impossible for me to help you amend...
Now, why didn't this pop up when I was out trawling google;-).
Good luck with your further development!
-- Glenn
That 5530 "odd" bug would have been virtually impossible for me to help you amend...
Now, why didn't this pop up when I was out trawling google;-).
Good luck with your further development!
-- Glenn
ASKER
the three keywords for the google are:
advantech linux xfree86
:))
advantech linux xfree86
:))
Yep, I went with geode & mediagx & Xwindows (several permutations)... Just goes to show I guess:-).
-- Glenn
-- Glenn
ASKER
hi gns,
i will have two more questions. i am sure that you will give good answers and i will give you more points.
from the link above;
everything was ok when i installed xsvga server with its rpm. however then i installed linux from scratch so no rpm s available. i cannot see xsvga server as a source tar ball around; everywhere it is rpm. also what is it exactly? do i need xfree86 also?
i use windowmaker as the window manager and would like to learn:
when it is opened, the first xterm window waits until you click the mouse. but i want it to open automattically. this should also be for the new xterms or windows i open.
i will appreciate your help.
thanks in advance,
best regards.
i will have two more questions. i am sure that you will give good answers and i will give you more points.
from the link above;
everything was ok when i installed xsvga server with its rpm. however then i installed linux from scratch so no rpm s available. i cannot see xsvga server as a source tar ball around; everywhere it is rpm. also what is it exactly? do i need xfree86 also?
i use windowmaker as the window manager and would like to learn:
when it is opened, the first xterm window waits until you click the mouse. but i want it to open automattically. this should also be for the new xterms or windows i open.
i will appreciate your help.
thanks in advance,
best regards.
Rolling our own distro are we? Adventuresome...:-)
The "source package" for the X server(s) are indeed the source tarball for XFree86. It's rather hefty, since it contains a lot. When RPM packagers make their packets, they have the option of making a _huge_ XFree86 rpm, with some sort of "auto-install" feature... which wouldn't be that easy to do, so most (if not all) split XFree86 into several more manageable parts to keep the individual part down in size, and to let you install just what is needed.
Remember to get the right version for your geode;-).
I'm not sure I've understood your second question, but perhaps you are referring to the "placement policy", which is how the window manager places individual windows on the screen. There are some different solutions to this: either the window manager needs the user to "click" where the window is to be placed, or the window manager has a strict "tiling" policy, or ... my favourite "sloppy placement", whis is to say the window manager will place the window on a "free root-wondow space" (not covering any other window) and failing that, covering as few windows as possible.
It's been a while since I used WindowMaker, but I seem to remeber this being a rather simple "point-n-click the root menu" matter, but I might remeber wrong.
I'll check up this as best I can (I'm on holiday, and just have a silly dualbooting portable with me... and it's windows ATM:).
I'll get back to you.
-- Glenn
The "source package" for the X server(s) are indeed the source tarball for XFree86. It's rather hefty, since it contains a lot. When RPM packagers make their packets, they have the option of making a _huge_ XFree86 rpm, with some sort of "auto-install" feature... which wouldn't be that easy to do, so most (if not all) split XFree86 into several more manageable parts to keep the individual part down in size, and to let you install just what is needed.
Remember to get the right version for your geode;-).
I'm not sure I've understood your second question, but perhaps you are referring to the "placement policy", which is how the window manager places individual windows on the screen. There are some different solutions to this: either the window manager needs the user to "click" where the window is to be placed, or the window manager has a strict "tiling" policy, or ... my favourite "sloppy placement", whis is to say the window manager will place the window on a "free root-wondow space" (not covering any other window) and failing that, covering as few windows as possible.
It's been a while since I used WindowMaker, but I seem to remeber this being a rather simple "point-n-click the root menu" matter, but I might remeber wrong.
I'll check up this as best I can (I'm on holiday, and just have a silly dualbooting portable with me... and it's windows ATM:).
I'll get back to you.
-- Glenn
ASKER
so what is x-svga server exactly? it is said to be a driver. does it do what xfree86 does in normal distros?
can you explain here?
i mean as you read in the URL above i need it. but it does not exist as a source tarball.
and i cant use rpm s as i install my own linux.
For the window manager question, i need that second policy.:))
because i dont want to have a mouse with my embedded.
by the way, have a nice holiday.:))
can you explain here?
i mean as you read in the URL above i need it. but it does not exist as a source tarball.
and i cant use rpm s as i install my own linux.
For the window manager question, i need that second policy.:))
because i dont want to have a mouse with my embedded.
by the way, have a nice holiday.:))
This is a Swedish mirror, check http://www.xfree86.org for a ftp or HTTP mirror closer to you: http://ftp.sunet.se/pub/XFree86/3.3.6/source/
Note that this is the last 3.3 version (which is right for you), and that you need to get most everything from this directory (at least X336src-1.tgz, X336src-2.tgz and X336src-3.tgz), and (as stated in the README in this directory) the files in the ../fixes directory. If you feel real adventurous, you can try a newer version and the "patches" you got, but I'd stick with what you already know to work... at least to begin with;-).
Running X mouseless isn't exactly just a question of "placement policy", there are some other considerations... I'll reboot this pile of ... into linux and see what I can find out regarding WindowMaker and running it mouseless.
I'll be back:-)
-- Glenn
Note that this is the last 3.3 version (which is right for you), and that you need to get most everything from this directory (at least X336src-1.tgz, X336src-2.tgz and X336src-3.tgz), and (as stated in the README in this directory) the files in the ../fixes directory. If you feel real adventurous, you can try a newer version and the "patches" you got, but I'd stick with what you already know to work... at least to begin with;-).
Running X mouseless isn't exactly just a question of "placement policy", there are some other considerations... I'll reboot this pile of ... into linux and see what I can find out regarding WindowMaker and running it mouseless.
I'll be back:-)
-- Glenn
A quick google search shows that most sites that pertain to mouseless or pointerless X windows actually a "accessibility" oriented, that is disability oriented. Example: http://wearcam.org/glinaccess/README.HTM
There probably are some good pointers in all this, as well as in the Accessibility HOWTO (found on the Linux Documentation project: http://www.tldp.org).
I'll be back with more...:-)
-- Glenn
There probably are some good pointers in all this, as well as in the Accessibility HOWTO (found on the Linux Documentation project: http://www.tldp.org).
I'll be back with more...:-)
-- Glenn
ASKER
thanks for the comments.
the only need for the mouse is to click once to open the first xterm terminal and also click once when my application window pops up. if we do have a placement policy, i will no longer need a mouse.
the only need for the mouse is to click once to open the first xterm terminal and also click once when my application window pops up. if we do have a placement policy, i will no longer need a mouse.
Ok, now rebooting...:-)
- Glenn
- Glenn
All aspects of WindowMaker (wel, at least the ones we're interrested in) can conveniently be "tuned and tweaked" via the WPrefs utility. You can finetune how windows are placed, how and when the window(s) recieve the input focus, "Hot-keys" or keyboard shortcuts to invoke window manager functions etc can be set etc etc etc.
On this portable I have Mandrake 8.1, and in that "guise" WPrefs get installed as /usr/X11R6/lib/GNUstep/App
When done, click Save... and things should be ready for mouseless operation:-).
Have fun
-- Glenn
On this portable I have Mandrake 8.1, and in that "guise" WPrefs get installed as /usr/X11R6/lib/GNUstep/App
When done, click Save... and things should be ready for mouseless operation:-).
Have fun
-- Glenn
ASKER
a funny question:
where do i set which window manager x server should use?
funny but i think i use fvwm2:))
where do i set which window manager x server should use?
funny but i think i use fvwm2:))
You'll of course find almost everything there is to know about WindoMaker at http://www.windowmaker.org/
When you start WPrefs, navigation gets a whole lot easier if you turn on the baloon help (just checkmark it).
-- Glenn
When you start WPrefs, navigation gets a whole lot easier if you turn on the baloon help (just checkmark it).
-- Glenn
Which window manager gets started varies with the method of starting X you use, whqat "method" of session control you use etc.
On a mandrake system (and RedHats too), it is controlled by the settings in /etc/sysconfig/desktop if not by a "separate" display manager.
Since you are rolling your own linux system, the most probable place for setting this would be in the users $HOME/.xinitrc, or the systemwide xinitrc file.
You're building a "KIOSK" application, right? In that case, fvwm2 isn't a bad choice for windowmanager... You should read (and follow) the advice in the KIOS HOWTO (you can find this at the LDP site I mentioned above, lets see... Look at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Kiosk-HOWTO.html).
-- Glenn
On a mandrake system (and RedHats too), it is controlled by the settings in /etc/sysconfig/desktop if not by a "separate" display manager.
Since you are rolling your own linux system, the most probable place for setting this would be in the users $HOME/.xinitrc, or the systemwide xinitrc file.
You're building a "KIOSK" application, right? In that case, fvwm2 isn't a bad choice for windowmanager... You should read (and follow) the advice in the KIOS HOWTO (you can find this at the LDP site I mentioned above, lets see... Look at http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Kiosk-HOWTO.html).
-- Glenn
ASKER
hi Glenn,
first of all i decided to continue with TWM.
My applicaiton is a videoconferencing application on the embedded PC told above. program has two thread one encodes and send video to the other side, the other thread gets video and displays it. my display library needs xserver.
by default twm opens an xterm. in the xinit man page it says that if .xinitrc is not found xterm is opened by default. i copied /etc/X11/xinit/xinitrc to root's home as .xinitrc but xterm is opeend by default when i startx.
i dont need xterm, ehat i only need is; when i startx start my application automatically.
i appened the following line at the end of .xinitrc but it didnot work.:
exec /root/tez/mytest
my promary concern is to make linux as minimal as possible as i only have a compact flash of 48 MB.:))
any comments?
regards...
first of all i decided to continue with TWM.
My applicaiton is a videoconferencing application on the embedded PC told above. program has two thread one encodes and send video to the other side, the other thread gets video and displays it. my display library needs xserver.
by default twm opens an xterm. in the xinit man page it says that if .xinitrc is not found xterm is opened by default. i copied /etc/X11/xinit/xinitrc to root's home as .xinitrc but xterm is opeend by default when i startx.
i dont need xterm, ehat i only need is; when i startx start my application automatically.
i appened the following line at the end of .xinitrc but it didnot work.:
exec /root/tez/mytest
my promary concern is to make linux as minimal as possible as i only have a compact flash of 48 MB.:))
any comments?
regards...
The "order" in the .xinitrc file is crucial.
All applications except the window manager (which should coime last and be run in the foreground) should be run in the background. This makes X exit when the window manager is exited. I would guess that a) in the .xinitrc there is a call to xterm, and b) if you exit twm, your application would "suddenly spring into life".
Some windowmanagers (like fluxbox) likes to exec so as to achieve the same effect as teh "foreground window manager".
Embedded linux is a large separate topic... that I've only looked at cursively... It has some great similarities to the "mini-distros" that boot of a flopy, or a bootable CD. Look at the useful info in tiwiki at http://www.toms.net/rb (I believe there is a large set of mini-distros mentioned under "floppy stuff" or somesuch).
-- Glenn
All applications except the window manager (which should coime last and be run in the foreground) should be run in the background. This makes X exit when the window manager is exited. I would guess that a) in the .xinitrc there is a call to xterm, and b) if you exit twm, your application would "suddenly spring into life".
Some windowmanagers (like fluxbox) likes to exec so as to achieve the same effect as teh "foreground window manager".
Embedded linux is a large separate topic... that I've only looked at cursively... It has some great similarities to the "mini-distros" that boot of a flopy, or a bootable CD. Look at the useful info in tiwiki at http://www.toms.net/rb (I believe there is a large set of mini-distros mentioned under "floppy stuff" or somesuch).
-- Glenn
Hm, close but no cigar: it is in wikiwiki, and is calle Other Floppy Things and Other CD Things respectively...
-- Glenn
-- Glenn
ASKER
i observed that XFree86 needs swapping. this is bad because i had to disable sqpping in order to increase the lifetime of my compat flash card.
by the way can you explain what xfree86_svga is?
what is the difference between it and xfre86?
by the way can you explain what xfree86_svga is?
what is the difference between it and xfre86?
With enough RAM, you shouldn't need swap, but... it looks like the vm in recent kernels do need at least a small swap to function as intended. One counterintuitive thing to try is to have a small ramdisk as swap.... (yuck! I'm unsure if that would even be doable).
As you say, it's a good idea to avoid excessive writing to the flash, so avoid having swap on it, or any "real" filesystem (ext2 has the "noatime" flag that avoids updating directories etc just by "visiting", but it's still a bit too "update-intense").
When you say xfree86_svga I take it you mean XF86_SVGA (which is installed by the XFree86-SVGA-3.3.6 rpm package on Mandrakes), which is one of several available X server binaries for XFree86 version 3.3.6 (the "old" version). This particular server supports generic SVGA chips, and a very substantial set of specific SVGA chips (amongst others the mediagx), so you can view it as a combined server and driver. This is actually true of all the version 3.3.6 servers (well, almost at least:-): XF86_S3 is the server and driver for (accelerated) S3 cards, XF86_S3V is for S3 ViRGEs, etc etc for several "chip families".
In version 4.x (the "new" version) of X, they have made a different approach to the splut between server and driver. Here the server is one binary (/usr/X11R6/bin/XFree86) that will load the driver you need/have specified dynamically (a bit like a shared object or dynamic link library). Thus it is easier for developers to use/implement generic acceleration features, that the driver will call as needed (depending on what the HW can do, of course). Information hiding, object oriented approach and al that:-). Generally much better, and this is where the future will be.
So why does the old version still linger around? Mainly because the 3.3.x version of XFree is very very old, and has a truly huge set of cards/chips supported. In some cases there is "fledgeling" support for a chip in 4.x, but the 3.3.6 version is more rubust and functional, so that is the one recommended (your case).
When version 4.x was developed, they had an eye out for compatibility. Thus a 3.3.6 binary "lives" well within a 4.x "framework"... It was done to make it safe to upgrade to 4.x ... if it didn't work out well with the new server and/or driver, you could simply "plopp" the old binary back into place (in fact, you don't even have to remove it, just change the symlink fo X (separate binaries and config files)).
With the MediaGX, version 3.3.6 is recommended, so that is the source version you should download, unpack, build and install. The cyrix driver for version 4.x simply doesn't support your version of the chip ... yet.
-- Glenn
As you say, it's a good idea to avoid excessive writing to the flash, so avoid having swap on it, or any "real" filesystem (ext2 has the "noatime" flag that avoids updating directories etc just by "visiting", but it's still a bit too "update-intense").
When you say xfree86_svga I take it you mean XF86_SVGA (which is installed by the XFree86-SVGA-3.3.6 rpm package on Mandrakes), which is one of several available X server binaries for XFree86 version 3.3.6 (the "old" version). This particular server supports generic SVGA chips, and a very substantial set of specific SVGA chips (amongst others the mediagx), so you can view it as a combined server and driver. This is actually true of all the version 3.3.6 servers (well, almost at least:-): XF86_S3 is the server and driver for (accelerated) S3 cards, XF86_S3V is for S3 ViRGEs, etc etc for several "chip families".
In version 4.x (the "new" version) of X, they have made a different approach to the splut between server and driver. Here the server is one binary (/usr/X11R6/bin/XFree86) that will load the driver you need/have specified dynamically (a bit like a shared object or dynamic link library). Thus it is easier for developers to use/implement generic acceleration features, that the driver will call as needed (depending on what the HW can do, of course). Information hiding, object oriented approach and al that:-). Generally much better, and this is where the future will be.
So why does the old version still linger around? Mainly because the 3.3.x version of XFree is very very old, and has a truly huge set of cards/chips supported. In some cases there is "fledgeling" support for a chip in 4.x, but the 3.3.6 version is more rubust and functional, so that is the one recommended (your case).
When version 4.x was developed, they had an eye out for compatibility. Thus a 3.3.6 binary "lives" well within a 4.x "framework"... It was done to make it safe to upgrade to 4.x ... if it didn't work out well with the new server and/or driver, you could simply "plopp" the old binary back into place (in fact, you don't even have to remove it, just change the symlink fo X (separate binaries and config files)).
With the MediaGX, version 3.3.6 is recommended, so that is the source version you should download, unpack, build and install. The cyrix driver for version 4.x simply doesn't support your version of the chip ... yet.
-- Glenn
splut == split
rubust == robust
-- Glenn (a.k.a. Le Grand Typo)
rubust == robust
-- Glenn (a.k.a. Le Grand Typo)
ASKER
hi gns
you can collect your points that i promised. my project is finally over.
thanks for your great help.
regards.
you can collect your points that i promised. my project is finally over.
thanks for your great help.
regards.
you say you included it with "this mail", but it hasn't shown up in the question body, so please provide it here (cut-n-paste, or a URL to the file would do nicely).
When we have it, we'll talk business:-)
-- Glenn