A quick guide on compiling XOrg 7.0 on DSL
Forum: DSL Tips and Tricks
Topic: A quick guide on compiling XOrg 7.0 on DSL
started by: ^thehatsrule^
Posted by ^thehatsrule^ on Nov. 28 2006,19:39
A quick (and dirty) guide.This was mostly done from < http://wiki.x.org/wiki/ModularDevelopersGuide >
(And from the XOrg mailing-list archive)
This has been tested with XOrg 7.
XOrg-git (to be 7.3 I gather, tested as of mid-Nov. '06) may be added later.
The order of installing the following stuff should be fine... please notify if they aren't.
What I used:
Fresh DSL livecd boot, nothing extra. Tested with 1.5 and 3.01 as user dsl.
Plenty of free ram. And cpu cycles.
And free disk space - about 3gb should be sufficient (depending on how much you install, and where you get your downloads).
mydsl:
gcc1-with-libs
gnu-utils
Note: I suppose you could use gcc-2.95 to conform with the kernel
extra:
perl-modules-stripped
Note: Since perl 5.8.0 is included in DSL, but is a stripped version, I created this package to house some required files.
Taken from a 5.8.x perl package, you'll need
/usr/share/perl/5.8.0/File/Basename.pm
/usr/share/perl/5.8.0/File/stat.pm
/usr/share/perl/5.8.0/File/Compare.pm
/usr/share/perl/5.8.0/File/Copy.pm
/usr/share/perl/5.8.0/Class/Struct.pm
(this was for git, I can't remember if there were less just for 7.0)
----------------------------------------
For the following:
- download them
- unpack them via tar (or whatever format you got them in)
- configure them via ./configure
<!> I used `./configure --prefix=/usr` to overwrite possible existing installations.
<-> If you don't, there's likely going to be a conflict, or something can't find something else - but you can get around this by specifying the lib dir by `export LD_LIBRARY_PATH=my_library_path` and point pkg-config to where it's .pc files are located by `export PKG_CONFIG_PATH=my_pc_path`.
- make && sudo make install
(scripting and loops can really help here!)
extra packages (from Xorg):
- mostly from gnu.org; downloads can be accessed by http/ftp at ftp.gnu.org
- else sourceforge, google, etc. - you'll find their official homepages right away. or see the first wiki link posted above.
pkg-config-2.1
m4-1.4.4
libtool-1.5
autoconf-2.57
automake-1.7.9
expat-1.95.8
libpng-1.2.8
zlib-1.2.3
fontconfig-2.2.3
freetype-2.1.9 (this one required 2 'make install's for some reason to have a 0 return value)
Optional:
some things (wiki says app/twm) require:
bison-2.3
flex-2.5.4
- Note: if you don't want to install these, you can comment/delete them out from the build script later on
if building mesa:
libdrm-2.0
Mesa-6.4.1 (I only used libmesa)
<!> for this you'll need to do `make linux-x86 && sudo make install`
<-> installed this to system-wide /usr/lib/... as well
<-> If you decide to use gcc-2.95 you'll have to remove the -std=c99 flags, since 2.95 only supports c89 (from the linux configs)
Notes:
- Unfortunately, gcc1 pacakge seems to come with pkg-config, so you'll just have to overwrite it.
- If you wish to use newer versions of certain packages with 7.0, you'll have to browse around for workarounds. Although I did try newer ones, there's just too many workarounds required! (so they won't be listed here, see the xorg mailing-list archive for more details if you want to go this way)
----------------------------------------
"Wait! We haven't even gotten X yet!"
Oh right... well I decided to go with tarballs - bzip'd.
I got mine from the official repository: < http://xorg.freedesktop.org/releases/X11R7.0/src/ >
You can either get the 'everything' dir... or everything else :P
Now, you get get the newest build-from-tarballs.sh script here: < http://gitweb.freedesktop.org/?p=xorg....alls.sh > and saved it to where_are_my_tarballs.
Now before you continue, you may have to remove some broken xrender stuff that something installed, unless you're using LD_LIBRARY_PATH and PKG_CONFIG_PATH. So (re)move /usr/lib/pkgconfig/xrender.pc and /usr/lib/libXrender.* If it's not there, then continue.
You may want to apply some security patches that have been made for 7.0 - I didn't know about them then.
And then I did:
cd where_are_my_tarballs
chmod +x ./build-from-tarballs.sh
PATH=install_path/bin:$PATH sudo ./build-from-tarballs.sh -m mesa_tar_extracted_dirname/Mesa-6.4.1 install_path &> build.log
Go build!
Optionally you can use `tail -f build.log` to view its current process (note that this may take up several more cpu cycles).
Notes:
- I suppose I should've tried the "-s sudo" options or something (because of a problem later described)
- If you didn't want Mesa, you don't need to include the -m part
- If you didn't use bzips, you'll want to specify -gz
- If you got the everything dir, use -e
- For a general usage, just run ./build-from-tarballs.sh
- If you don't want certain parts, edit ./build-from-tarballs.sh, and prepend # to comment out lines (ie docs - since DSL by default won't use em manpages)
----------------------------------------
Running X.
cd ~/
Edit .xserverrc to point to your new Xorg binary. You might want to add stuff to ie PATH=install_path/bin:$PATH and LD_LIBRARY_PATH=install_path/lib here.
For some reason, I can only `startx` with super-user priveleges, ie `sudo startx`. Haven't been able to find a fix/workaround yet or what exactly is going wrong.
You'll probably end up seeing it try to auto-generate a xorg.conf here since you probably won't have one yet.
Well, it didn't work for me since it said that the system was using a framebuffer console and you'd need to specify the busid's of the video cards. So I just downloaded one. Or you could try running xorgconfig, etc.
You could save the xorg.conf to the general /etc/X11 or install_path/etc/X11 (if you decide on making a self-contained package), among other places.
Now it should load up, tada! yay! (hopefully). Enjoy the fonts!
The common error I get without running as root is on xf86ReadBIOS: Failed to read /dev/mem (Operation not permitted) in the X log, and it fails on Fatal server error: xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted)
I have only been satified by starting xdm as a service to avoid the sudo startx.
After loading dsl-dpkg; apt-get update; apt-get install xdm,
/etc/init.d/xdm was edited to point to my new installation.
Created ~/.xsession - this is run by xdm for login stuff.
I placed
cd ~
and the usual PATH and LD_LIBRARY_PATH (as described above) in there
and appended the current .xinitrc contents (ie `cat .xinitrc >> /xsession`)
Note: if you use xdm you need at least one user's password set!
You can either boot with "dsl secure" or use sudo passwd (for root) and sudo passwd dsl (for user dsl)
Now start it up as root, like using `su -c "/etc/init.d/xdm start" -`
(Of course this isn't very secure since anyone can still kill this via ctrlaltbksp, etc. so you may want to disable that or use something like xlock, etc.)
And now you should have a pretty login screen (like what SU had in his older post in this forum). I suppose for permanence this could be added to some startup/init script.
I know this is kind of a rushed guide, but it may serve its purpose. I guess it wasn't as quick as I thought...
I know there is a problem with this, but I still think it's good as a guide for those who want to try it out.
Any feedback/comments are welcome!
Thanks to the XOrg team for their great work!
Posted by ^thehatsrule^ on Dec. 13 2006,16:40
Looks like there isn't much interest in this, but I'll post this part anyways just in case someone wants the latest (and greatest?) and for future reference. These notes are based on the previous (above). Also some news: some of you may know that 7.2 final will probably be available sometime soon.-----------------------------------
xorg-git as of mid Nov, 06
Heavily based on the guide from < http://wiki.x.org/wiki/ModularDevelopersGuide > (*)
Replaced packages:
autoconf-2.59
automake-1.9.6
( previous version installations were uninstalled with `sudo make uninstall`)
Additional packages:
gperf-3.0.2
libxml2-2.6.26 ( < ftp://xmlsoft.org/libxslt/ > )
libxslt-1.1.16 ( 1.1.18 causes gcc problems )
Bleeding-edge dev code:
drm-cvs
Mesa-cvs
** all the above is now built and installed in system **
Note: Looks like these also got moved to git repositories, so you should now use
drm-git ( < http://www.mesa3d.org/repository.html > )
Mesa-git ( < http://www.mesa3d.org/repository.html > )
I install git on another machine, then transferred the files, so I am unaware of the requirements to install git on a default session of DSL. (git: < http://www.kernel.org/pub/software/scm/git/ > )
xorg-git (*)
xcb-git ( xcb is the new and shiny replacement for xlib )
This time we will be using the build.sh script instead of build-from-tarballs because ... we aren't using tarballs now
Then I adapted the build lines to:
PATH=/tmp/modular/bin:$PATH ./util/modular/build.sh -m /tmp/Mesa-git /tmp/modular &> build.log
<!> Note: At this time, I had to pass --disable-dmx and --disable-xprint as well (because they were broken). Also, a new input system was in place, and only the default mouse, keyboard, and evdev input modules could be built. You may want to pass -n to continue even if there are errors during build. (Or comment them out in build.sh).
Hopefully now it will build, and now you have the binaries for the latest xorg to play with
-----------------------------------
This section applies to the both posts in general:
If you don't want to build certain things (like docs *cough*) you can easily delete them in build script, or delete them in the final output dir (docs, man, etc. folders). There's probably some apps you will probably won't use either.
Also, if you don't plan on using the dev files, you can cut out
[file extension] (optional directory to seach for/delete)
.h (include)
.pc (pkgconfig)
.a
.la
.m4 (aclocal)
others?
(and then take out empty dirs)
For example, you can use something like grep -e "\\.h$", and for directories you can use "\/include\/"
Other things to take out:
locale files (ie keep the ones you only use)
fonts (these take up quite a bit, but now theres many... a lot... to choose from. You get the idea.)
Enjoy
Posted by WDef on Feb. 01 2007,23:17
VERY impressive effort, I like heroic compiles on dsl :=)Any chance you might be able to build a massive extension out of this (unc perhaps)?
I think we people with Intel915GM integrated graphics in our laptops need XOrg6.9+ to stand a chance of getting graphics acceleration.
Posted by ^thehatsrule^ on Feb. 03 2007,05:03
Well, I haven't gotten around to getting a better fix/workaround for the main problem (startx only by root), so that was what was stopping me from easily making an extension. Maybe it needs some debian/knoppix patches? I did plan on making an .uci with some of my install/configure scripts though.
Posted by mikshaw on Feb. 03 2007,06:44
This project is beyond anything I've tried so far. The last time I tried to compile an X system was a zipslack box, and that was before i knew how to use it =o)Anyway, my point in posting this was to say that I remember reading that some systems require X to be built with setuid root. That was xfree86, but i guess it might still apply here.
This is just me guessing, though, as usual. Thought it might apply.
Posted by Juanito on Feb. 03 2007,10:29
| Quote (WDef @ Feb. 01 2007,22:17) |
| I think we people with Intel915GM integrated graphics in our laptops need XOrg6.9+ to stand a chance of getting graphics acceleration. |
I think I read somewhere that 855patch/855wrap might get this working with XFree86
Posted by ^thehatsrule^ on Feb. 03 2007,19:53
| Quote (mikshaw @ Feb. 03 2007,01:44) |
| Anyway, my point in posting this was to say that I remember reading that some systems require X to be built with setuid root. That was xfree86, but i guess it might still apply here. This is just me guessing, though, as usual. Thought it might apply. |
The makefile/build scripts automatically sets setuid. I even set it manually just to make sure.
However, the problem is due to the console/vt devices in dsl, which I have no real experience with. (Fails trying to open it, with Permission Denied)
Posted by WDef on Feb. 04 2007,11:19
| Quote |
| 855patch/855wrap might get this working with XFree86 |
If you can dig this up I'd be grateful. The drivers for 915 from http://dri.freedesktop.org/wiki/ require XOrg6.9RC1 or later to compile - if there's another way ...
BTW that site has statically-linked precompiled binaries for XOrg - I installed them on fedora core 4 so I could build the 915 drivers and get graphics acceleration/direct rendering (fc4 only ever supplied Xorg6.8).
I tried these static binaries on dsl a while ago but didn't seem to run - glibc problem I think. Might work on dsl-n though ??
Posted by Juanito on Feb. 04 2007,12:05
Unfortunately, searching on 855patch AND xfree86 AND 915 didn't turn up the article I was thinking of.I think the 915GM chip has the same problem as the 855GM chip I have, in that the BIOS cannot tell the X-Window manager how much RAM to allocate for graphics.
You could try booting DSL in terminal mode and trying to run 855patch and 855wrap (they are posted in the modules section of the DSL repository) - they will come back with a message about whether your chipset is supported and if you need to use patch or wrap.
If 855patch or 855wrap work then you may be able to get graphics acceleration using XFree86.unc and the i810 and dri modules - it works for me.
Posted by ^thehatsrule^ on Feb. 04 2007,16:54
| Quote |
| I think the 915GM chip has the same problem as the 855GM chip I have, in that the BIOS cannot tell the X-Window manager how much RAM to allocate for graphics. |
Posted by Juanito on Feb. 04 2007,18:07
As in how much memory to allocate - yes (after running 855wrap).
Posted by WDef on Feb. 06 2007,17:03
855wrap says:| Code Sample |
| No i855GM chipset found! |
Not surprising I suppose.
Posted by Juanito on Feb. 06 2007,17:38
Ah, well - since even the 855 uses a driver named 810 it was worth trying I guess
Posted by Juanito on May 12 2007,08:02
I'd been trying to compile xorg 7.2 for DSL/DSL-N when I remembered this post...I've been downloading the source files one by one when the compile complains about them being missing, but in the end it might be easier to download all of them.
Is there an easy way to download the entire contents of an on-line directory?
Posted by curaga on May 12 2007,09:08
rsync?Juanito, try XFree 4.6.0, that may support i915, and is only one download...
Posted by Juanito on May 12 2007,11:06
Hmm - I read the rsync man pages and tried many things, but never got past this: | Code Sample |
| # rsync ftp.x.org::ftp/pub/X11R7.2/individual/everything/*.tar.bz2 /tmp Password: @ERROR: auth failed on module ftp rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(420) |
I tried with password "", "anonymous", "guest" but no luck. Does the other end have to be enabled for rsync?
Edit
----
Got it with:
| Code Sample |
| wget -c --retr-symlinks ftp://ftp.x.org/pub/X11R7.2/individual/everything/*.tar.bz2 |
Posted by Juanito on May 19 2007,09:44
I 've been working on building xorg 7.2 from the "build from tarballs" script.Unlike ^hats^, I tired the script without the -m (mesa) switch but it halts at the application "xdriinfo" with the message "error: cannot find GL library - make sure Mesa or other OpenGL package is installed"
I'm booted from a DSL 3.3 frugal hd install using the tiny X server (or whatever the default is called) and used the prefix /usr/X11R7 with the tarballs script to avoid overwriting anything in /usr/X11R6.
If I try to compile Mesa, I get an error "cannot stat `libGL.so.1.2': No such file or directory" - it's true that this library is not present, but this seems like a catch-22 situation - how can I build xorg if I need to have xorg/xfree86 in the first place? I get an error (perhaps not the same one) whether I try to build with or without hardware acceleration (make linux-x86 or make linux-dri-x86).
The aim is to make an xorg.unc extension, any suggestions would be much appreciated.
Posted by ^thehatsrule^ on May 20 2007,03:10
Do you really need dri things if you aren't going to build mesa? Perhaps the script doesn't really account for everything without -m. You could just try commenting it out from building.My guess about that mesa error is that something went wrong building it before that, so it can't find the file.
But I hope you'll try building mesalib
Also, why are you trying to build a unc first? My understanding is that this can be all self contained - so uci should be optimal in this case... but this is misc. now.
Posted by Juanito on May 20 2007,03:42
In the end I managed to build mesalib by loading the XFree86/XFree86-dev extensions - xdriinfo built OK when I compiled it at the point the build script failed but on the next full build it couldn't find mesa.I'm wondering if trying to build xorg in /usr/X11R7 is the problem with mesa/xdriinfo. I can try to build a uci extension - DSL/uci-wise, where would be the best location to build xorg - /usr, /usr/X11R6, /usr/X11R7, /opt or?
Posted by ^thehatsrule^ on May 20 2007,05:20
uci wise, something in /opt should be fine... such as /opt/xorg72 ?The output directory shouldn't really affect much....
Afaik /usr/X11R? is not used since xorg has gone modular. In more traditional systems, libs and binaries are _typically_ placed in system-wide directories (ie /usr/lib* , /usr/bin, etc) and the rest in /usr/xorg
Mixing different versions might be dangerous... if you plan on building libmesa (did you get libdrm?), make sure you get a corresponding version for those as well and that you pass -m to the script.
Posted by Juanito on May 20 2007,06:06
So I guess either /opt/xorg72 or /usr would be the output directory to aim for - the problem with the build_from_tarballs script is that you cannot pass things like --prefix=/usr or --exec-prefix=/usr (so that *.conf files end up in /etc).I compiled the latest version of libdrm with the latest version of libmesa - in order to compile I had to load XFree86.unc and XFree86-dev.unc but I did not load these before starting the latest build_from_tarballs attempt which is maybe why it failed at xdriinfo.
libmesa compiled into /usr/local (there is no ./configure script) so I guess I will have to modify the makefile to get it to compile elsewhere. When I tried the -m switch with the destination of the libmesa sources, the compile failed at xorg-server complaining that /libmesa/src/GL/include/array_cache (or something like that) was missing.
Repeating all this is slightly tedious on a 267MHz Pentium II...
Posted by curaga on May 20 2007,14:46
Building X on 267Mhz? You have my respect...Xorg 6.9.0 took 4 hours on my P3-1066...
And gcc 4.0.3 bootstrap + test suite was almost 24 hours..
Posted by ^thehatsrule^ on May 20 2007,18:59
Yes, that script will place everything into the output dir...What do you mean by "latest" version? from cvs/git? From my experience... only a few versions work with certain builds of x
hmm.. the older versions of libmesa prompted you for the install dir, but I don't think /usr/local mattered (with git)... but I can't seem to remember.
Posted by Juanito on May 21 2007,03:44
| Quote |
| What do you mean by "latest" version? |
Mesalib-6.5.3 and libdrm-2.3.0 - these seemed to be the latest, non-testing, versions.
Mesa seems to need the Xlib headers - I'm wondering if the ones from XFree86-devel are too old and I shouldn't compile libX11 from the 7.2 release before I compile mesa
Posted by ^thehatsrule^ on May 22 2007,07:02
The wiki seems to suggest using bleeding edge libdrm for 7.2 (tho it is outdated)tbh, I ended up doing a lot of trial and error myself... most of the problems were solved just by changing a lib/program's version.
But I can't seem to remember if I did encounter your problem(s) or not. I might try 7.2... but the amount of time it takes to build just puts me off slightly.
I applaud you for trying it out on that machine as well
Posted by Juanito on May 23 2007,05:18
Since mesa depends on libdrm and libdrm in turn depends on glproto, xf86vidmodeproto, libXxf86vm & libXmu I decided to run the build_from_tarballs script until libXmu and stop there to build libdrm and mesa before continuing.The tarball script will not run with prefix=/usr, presumeably because it would overwrite the few files tinyX uses there, so I used /usr/local. The tarball script runs fine to libXmu and libdrm compiles fine but mesa complains that it cannot find various header files which are actually in /usr/local/include.
I could copy the header files into /usr/include but I guess it would be cleaner to do this "properly". I believe the following will let mesa know where library and package config files are:
| Code Sample |
| # export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH # export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:$PKG_CONFIG_PATH |
but how do you do this for header files?
Posted by ^thehatsrule^ on May 23 2007,15:49
Some info here: < http://www.network-theory.co.uk/docs/gccintro/gccintro_23.html >though it says gcc should auto-search the local dir...
Somehow I seem to remember doing `ln -s /usr/local/include/X11 /usr/include/X11` at one time though (maybe I left out a step?). But I'm pretty sure that I build libdrm and libmesa before building X (I assume they just used the headers)
Posted by Juanito on May 26 2007,06:24
So... I managed to compile mesa after switching from mesalib-6.5.3 to mesalib-6.5.2 - it seems mesa was looking for a driver, nouveau.drm, that wasn't present in libdrm-2.3.0.This time I use --prefix=/usr/local and after compiling mesa with "make linux-dri-x86", the build_from_tarballs script runs from beginning to end without error - although I did not use the -m /path-to-mesa-sources/ switch.
As a test (I need to go back and compile with the -m switch), I tried to run X without a .conf file and got this:
| Code Sample |
| X Protocol Version 11, Revision 0, Release 7.2 Build Operating System: Linux 2.4.26 i686 Module Loader present Unable to locate/open config file Matrox Graphics, Inc. MGA 2164W [Millennium II] AGP rev 0 New driver is "mga" LoadModule: "glx" Failed to load module "glx" (module does not exist, 0) ... Fatal server error: Cannot run in framebuffer mode |
I'm guessing the glx module is missing either because I did not use the -m switch or because I did not build mesa using make "make linux-x86"
Any other ideas would be welcome
Posted by curaga on May 26 2007,09:03
Use "Xorg -configure" and try with that conf it produces..Where are your X modules?
Posted by ^thehatsrule^ on May 26 2007,20:13
Your fatal error is "cannot run in fb mode". I also experienced this problem... apparently to use the "auto xorgconfig" in current XOrg, you can't be using fb (which DSL uses) and so you need to specify a xorg.conf .For your glx problem.. I'm also assuming it's because you built without -m (since glx = opengl).
And it did look like your problem was another one of the "version incompatiblilty" situations -- nice to see you solved it.
Posted by Juanito on May 27 2007,03:43
I re-ran the MesaLib compilation with "make linux-dri-x86" and used the -m switch in the build_from_tarballs script.A message came up in the compilation of xorg-server about finding mesa sources and glx so I guess I'm on the right track - I ran out of ramdisk at some point in building fonts so it's hard to tell for sure.
I guess I'll have to do the full compilation in stages making unc's as I go along or perhaps build to /opt with a persistant opt...
Posted by ^thehatsrule^ on May 27 2007,04:39
wow... you've been doing all of this in swap? At the very least, I'd recommend a symlink /opt/xorg72 to some location on a hard disk.
Posted by Juanito on May 27 2007,05:05
Well, not exactly in swap - although the cpu is a 267MHz Pentium II, it has 512MB RAM plus 1GB swap. With a frugal toram hd install, this leaves me +/- 400MB for /home according to torsmo.I like the idea of the /opt/xorg72 symlink, maybe I'll try that next...
Posted by Juanito on May 29 2007,03:59
I ran the build_from_tarballs script again using /opt/xorg72 with a symlink to hd - the compile ran without error, but the first thing I noticed is that X will only run as root. When I compiled to /usr/local, X would run as user DSL.From this excerpt from the compile checks, it looks like the hardware acceleration built OK - maybe the second line explains why X will only run as root (unfortunately I don't keep the output from the /usr/local build):
| Code Sample |
| Building xserver module component xorg-server-1.2.0... ... checking to see if we can install the Xorg server as root... yes ... checking for XLIB... yes checking for GL... yes Creating destination directories for mesa module ... DONE Creating destination directories for glx module ... DONE Checking that the source files exist for mesa module ... DONE Checking that the source files exist for glx module ... DONE Deleting existing files for mesa module ... DONE Deleting existing files for glx module ... DONE Linking files for mesa module ... DONE Linking files for glx module ... DONE ... |
Anyway, after playing around with the xorg.conf file, things seem to work and (according to Xorg.0.log) the glx and dri modules load.
I guess I need to solve the problem of why X will only run as root from /opt/xorg before I can think about making an extension - maybe this is due to the symlink to hd and the permissions on the hd?
Is it possible to make a uci extension after compiling to /usr/local?
Posted by ^thehatsrule^ on May 29 2007,04:57
It looks like you've got the same root problem - which prevented me from creating an extension in the first place.Afaik if it's run with root privs, it'll set permissions on executable files with something like 4755. But from my previous finds, there's a more in-depth problem (the fb console) which I'm not sure of.
Did you not install to /opt/xorg72 using the build script? If so, everything should be able in there, and you can just with that.
Posted by Juanito on May 30 2007,15:59
| Quote |
| Did you not install to /opt/xorg72 using the build script? If so, everything should be able in there, and you can just with that. |
I installed to both /opt/xorg72 and /usr/local using the build script with the same options - what's puzzling me is that x starts fine from /usr/local but only as root from /opt/xorg72.
Did you try building to /usr/local?
Posted by ^thehatsrule^ on May 30 2007,18:40
No, I didn't. So you set your output directory on the build script to /usr/local ... and you can startx by a regular user? (Side note: it looks like ubuntu doesn't allow startx by a regular user... but it uses gdm by default)Do you notice anything different on the files themselves (comparing files in /opt/xorg72 and /usr/local ... I'm assuming you did the same build steps for each)? What if you move/copy the files over from /opt/xorg72 to a place in /usr/local (saving your data first, of course)? If there are no visible differences, perhaps it's hardcoded somewhat to work for /usr ?
But it looks like you've found a workaround that works -- I suppose creating a .unc would be the best for now. If that works, congrats on making the first extension
Posted by Juanito on June 03 2007,07:14
I'll plan to go with a unc extension based on compiling to /usr/local once I finish a clean compile - I have mixed feelings about this since the extension will probably end up larger than DSL itself, but anyway...I was planning to remove the doc, man, .h, .pc and .m4 files - didn't realise you could remove the .a and .la files (what are these?) so I'll take these out too.
It would probably make sense to create an additional font extension as xorg came with a bunch of 75 and 100pdi Freetype fonts as well as some Truetype. Is there a minimum set of fonts that xorg/DSL can work with? The idea would be to remove all but a few fonts so that DSL looks same as with the tiny X server.
Posted by ^thehatsrule^ on June 03 2007,07:36
I think those files are precompiled static libraries... (at least for .a, but .la looks similar)As for required fonts, I believe you only need one version of the "fixed" font as a minimum requirement.
Posted by curaga on June 03 2007,09:07
umm.. How will your extension be bigger than DSL, when in Geexbox-HD Xorg added only 14mb?Did you also build cyrillic, CID and other fonts? If you did, just remove 'em, only 75 & 100 dpi will be needed to that font extension..
Posted by Juanito on June 03 2007,11:03
| Quote |
| umm.. How will your extension be bigger than DSL, when in Geexbox-HD Xorg added only 14mb? |
| Quote |
| Did you also build cyrillic, CID and other fonts? If you did, just remove 'em, only 75 & 100 dpi will be needed to that font extension.. |
font-util
font encodings
font-adobe-100dpi
font-adobe-75dpi
font-adobe-utopia-100dpi
font-adobe-utopia-75dpi
font-adobe-utopia-type1
font-arabic-misc
font-bh-100dpi
font-bh-75dpi
font-bh-lucidatypewriter-100dpi
font-bh-lucidatypewriter-75dpi
font-bh-ttf
font-bh-type1
font-bitstream-100dpi
font-bitstream-75dpi
font-bitstream-speedo
font-bitstream-type1
font-cronyx-cyrillic
font-cursor-misc
font-daewoo-misc
font-dec-misc
font-ibm-type1
font-isas-misc
font-jis-misc
font-micro-misc
font-misc-cyrillic
font-misc-ethiopic
font-misc-meltho
font-misc-misc
font-mutt-misc
font-schumacher-misc
font-screen-cyrillic
font-sony-misc
font-sun-misc
font-winitzki-cyrillic
font-xfree86-type1
font-alias
Can I manage with just this?
font-util
font encodings
font-adobe-100dpi
font-adobe-75dpi
font-alias
Posted by Juanito on June 06 2007,18:33
I've got a small problem here - when I try to start xorg in /usr/local, it complains that it cannot find lib files that I've verified are in /usr/local/lib. This doesn't happen when I start xorg in /opt/xorg72 but then I have to run startx as root.I've tried adding /usr/local/lib to $LD_LIBRARY_PATH and I've checked that /usr/local/bin is in $PATH but this doesn't help. I suppose I'm missing something obvious, but what?
Posted by ^thehatsrule^ on June 06 2007,18:59
I usually replace the symlink .../bin/X with a wrapper script that sets up the environment (though usually this is out of /usr since /usr/local/lib should be searched by default? - esp. if you set the script to build there).| Code Sample |
| export LD_LIBRARY_PATH=/usr/local/lib Xorg |
Posted by curaga on June 07 2007,16:48
About fonts:| Quote |
| Can I manage with just this? font-util font encodings font-adobe-100dpi font-adobe-75dpi font-alias |
Also font-cursor-misc might be needed..
Posted by Juanito on June 08 2007,09:54
| Quote |
| export LD_LIBRARY_PATH=/usr/local/lib Xorg |
Thanks - I hadn't thought of doing it like that - 'trouble is I still get the same error:
error while loading shared libraries: libXfont.so.1: cannot open shared object file: no such file or directory
In /usr/local/lib I have the following:
libXfont.so --> libXfont.so.1.4.1
libXfont.so.1 --> libXfont.so.1.4.1
libXfont.so.1.4.1
If I use a symlink to a previous compile:
/opt/xorg72 --> /mnt/sdb4/opt/xorg72
Then I do not get this error, but I have to use "sudo startx". However, if I build a unc extension based on /opt/xorg72 then I get the same libXfont error.
This starts to get tedious...
Posted by curaga on June 08 2007,11:32
Maybe Xorg hardcoded the location of that lib somewhere, thus not using $LD_LIBRARY_PATH..
Posted by Juanito on June 09 2007,17:40
After going nowhere fast, I decided to make a huge dsl extension out of the compile to /opt/xorg72 and load it on a different machine booting from USB. Interestingly, I did not need to run startx as root, xorg found all of the libraries on its own and it worked I've been wondering for a while if the file permissions are somehow messed up on the DIY frugal hd install I compiled xorg on - maybe the problems I've been having bear this out.
Anyway, xorg-7.2 recognises the Intel855 on my other machine (and says it can handle the Intel915, since I recall WDef mentioned this), it looks like I will not need 855wrap and the hw acceleration seems to work.
Now all I have to do is reduce the extension from 220MB and figure out how to make a uci...
Posted by ^thehatsrule^ on June 09 2007,18:05
hmm interesting.... did you try your extension after booting with "dsl base norestore" -- or basically like a clean livecd/usb?First you should try renaming it to .tar.gz - reboot cleanly back into "dsl base norestore" and load it again. Since it's only in /opt/xorg72 it should work. Now for uci extension... search wiki: extension
Posted by Juanito on June 10 2007,06:10
| Quote |
| hmm interesting.... did you try your extension after booting with "dsl base norestore" -- or basically like a clean livecd/usb? |
I presume you refer to the frugal hd install - no, because the DSL splash with the boot options prompt does not come up on this machine. Booting with "dsl base norestore" would mean modifying lilo.conf and then modifying it back again and this machine takes forever to boot (it also refuses to boot from cd).
| Quote |
| First you should try renaming it to .tar.gz - reboot cleanly back into "dsl base norestore" and load it again. Since it's only in /opt/xorg72 it should work. |
The original compile was made with a symlink /opt/xorg72 --> /mnt/sdb4/opt/xorg72. Unfortunately the frugal hd install machine does not have enough RAM to restore the extension as .dsl or .tar.gz - I could eventually try this with a uci or the unc I made from a compile to /usr/local (built in stages to cope with the lack of RAM).
| Quote |
| Now for uci extension... search wiki: extension |
I must have been suffering from temporary blindless when I went there before - I see it now...
Posted by Juanito on June 12 2007,09:25
I spent some time to eliminate the /man, /doc, .h, .pc, .m4, .a & .la files in the compile as suggested by ^hats^ with the result that the extension is now a trim 180MB...There are still executable files such as xprint (20-30MB...) that I believe could be eliminated and fonts that could be removed, but it's hard to imagine that the extension will ever be smaller than DSL itself - or DSL-N for that matter since it works on rc4 too.
If there is some interest for those who use new graphics chips and need hw acceleration, etc I could post (probably literally) the extension but I'm not sure the size is exactly in the spirit of DSL - what does anybody think?
Posted by ^thehatsrule^ on June 12 2007,19:06
I think you can only trim it if you split it into separate extensions, which may complicate things (i.e. default paths for things...)But I'm interested in trying it out (you can start it without being root now?).
It is rather large (OO2 is at ~125mb but has all of oowriter, oocalc, etc.), and unless there is a demand for it, I don't feel that it's necessary to post it as-is, but that's really up to you.
If everything in the extension works out, perhaps the next step would be trimming it even further to be acceptable as an official mydsl extension. (ie decide what default things to include - such as just using the basic mouse and k/b driver).
A bit off-topic: would there be interest in XFree86 4.6? (though FSF disagrees with their new license)
(btw, I forgot to mention that xcb is xlib's replacement, which I hid in the first page)
Posted by Juanito on June 13 2007,05:24
| Quote |
| (btw, I forgot to mention that xcb is xlib's replacement, which I hid in the first page) |
This gives scope for some serious size reduction if I only need xlib or xcb
libX11.so.6.2.0 = 20.8MB
libX11-xcb.so.1.0.0 = 118kB
and there are many libs named libxcb-*
| Quote |
| (you can start it without being root now?). |
Yes, I need to be root to start it via a symlink to hd, but when I make a .dsl or .uci extension from the symlink I can start it without being root (tested on two different machines and also with DSL-N).
Posted by ^thehatsrule^ on June 13 2007,06:41
Since I did do the same thing (symlink to hd) perhaps it looks at the permissions on the mounted device...btw, I think both are included by default for compatibility, tho I think xcl is supposed to address that... (may not have been implemented into 7.2 release yet though)
Posted by curaga on June 13 2007,10:55
At least XFree 4.6 is easier to build than Xorg 7.2, and it should support new chipsets also..So new XFree wouldn't hurt.
Back to topic: Are there all XvMc files?
Printing stuff could be removed, I think..
You should separate Xdm into it's own extension..
Also these aren't needed:
ico, occlock, rstart, rstartd, twm, x11perf, x11perfcomp, xcalc, xclock, xedit, xgc, xkbbell, xload, xmag, xman, xpsimplehelloworld, xpxthelloworld
These are among "printing stuff": xdpr, xphelloworld, xplsprinters, xpr, xprehashprinterlist
Posted by Juanito on June 13 2007,11:31
Yes. there are some files such as libXvMC.so.1.0.0, libi810XvMC.so.1.0.0, libviaXvMC.so.1.0.0, etc - are these deletable?I will make another round of deletion to take out the unneeded /bin files (Xclock, etc) and printing stuff (although I have never managed to print in DSL using APSfilter, CUPS or anything else, so I wonder if this will work...) and see how easy it is to identify the xdm files. There are also some Mac and Windows libs I can remove.
Thanks for the pointers.
Posted by curaga on June 13 2007,12:09
No, don't delete Xvmc libs - they provide video accel for intel and via..
Posted by ^thehatsrule^ on June 13 2007,16:33
Perhaps providing a totally stripped extension would be best as far as "easy" goes (and placing everything else in another for now).The easiest would be the things in .../bin and .../lib because you can easily modify $PATH and $LD_LIBRARY_PATH. I regularly use xcalc... and xedit can come in handy, and other users would want some specifics, so imo providing the "extras" extension would be good enough for now (though older ones may already exist in DSL). Other things like using ModulePath in the xconfig could be used..
If you look at the current XFree86 extension, I think it contains the bare minimums, and only has the opengl libraries as extras. Typically you'll need to load gnu-utils that contains all the other goodies (xrandr, etc. though I don't think that's all of it either)
I guess `grep -i xdm -r *` could do the trick?
Posted by WDef on June 18 2007,21:32
@Juanito:What's actually the problem you're having making a uci?
Posted by Juanito on June 19 2007,07:33
Temporary wiki blindness - I've made and tested xorg72.uci on a couple of machines and it works fine. The file size is currently 175MB so I'm having a few problems to upload it anywhere...
Posted by WDef on June 19 2007,09:54
Great work, thx Jaunito and all.Looking forward to trying this - maybe I'll finally get to see graphics acceleration with dsl and the 915GM chipset.
Posted by Juanito on June 19 2007,10:24
Maybe - the first thing I found is that the i915 module is required for drm, the i830 works fine for everything else though. In DSL-N the i915 module is too old for drm, but everything else works OK.
Posted by curaga on June 23 2007,09:34
If you get it below 100mb, upload it to Rapidshare.Now it could also be split in two, but that 2,5h timeout between downloads for unregistered rapidshare downloaders is a bit much...
Posted by Juanito on June 24 2007,04:00
Mailed to Robert yesterday - hopefully it shouldn't take too long to get there...
Posted by ^thehatsrule^ on June 30 2007,06:45
Notes on (juanito's) extension:- xcb libs do not seem to be included, so you cannot run xorgconfig as suggested by the .info (note that you'd also probably need to make a wrapper to see /opt/xorg72/lib, or see suggestion #2)
Confirmations:
- Originally I did not have enough memory, so I used symlink from /opt/xorg72 to a directory on a hard drive, and it did not work (permissions error upon startx). Increasing the memory seems to work, but I was not using any swap. Perhaps suggesting in the .info that a lot of memory is required? (512mb?) I wonder if this would work with a persistent /opt. I'm assuming doing a .tar.gz would work with my own builds of xorg as well... Perhaps this has to do with the .tar.gz unloading onto /ramdisk ?
- uci conversion working
Suggestions:
- I think for xorg.conf, using /etc/X11 is still common, and will probably take precedence before /etc/X11/XF86Config-4 as well.
- suggest how to use the binaries in /opt/xorg72/bin (edit PATH and LD_LIBRARY_PATH in .xserverrc or create a source script that sets these)
- script to automagically make (a minimal) xorg.conf and edit .xserverrc
Posted by Juanito on June 30 2007,10:42
| Quote |
| - xcb libs do not seem to be included, so you cannot run xorgconfig as suggested by the .info |
| Quote |
| Originally I did not have enough memory |
| Quote |
| I think for xorg.conf, using /etc/X11 is still common |
| Quote |
| script to automagically make (a minimal) xorg.conf and edit .xserverrc |
Posted by curaga on June 30 2007,10:58
Is a xorg.conf included? Something default, vesa?
Posted by Juanito on June 30 2007,11:26
No - because:1. xorgconf was supposed to be included and seems to work well
2. there seems to be plenty of example xorg.conf available using Google
3. nothing to do with vesa, but I haven't finished figuring out drm, etc (and yes, it should have been i915
)I think it make sense to leave the uci as-is, but let me see if I can make the slightly larger .tar.bz with xorgconfig included available.
BTW - this extension can definately be a "community project" should any owners of a 50MB os want to mess with an extension 3x the size...
Posted by WDef on June 30 2007,11:55
Is the i915 driver in there together with the i810? If so I might have acceleration for the first time with my laptop on dsl (sorry to repeat myself). I did compiling of dri ages ago because fedora core 4 did not ship with either the right version of xorg or a working i915 module. But thankfully I didn't have to compile xorg - instead I installed a "foreign" xorg precompiled.Re: size. I know we don't like to compare dsl to Puppy around here, but Puppy contains a stripped down xorg (so you have to install dri). It might be worth at some stage examining what they took out and what thet left in, since their iso comes in at 80MB including xorg.
Posted by Juanito on June 30 2007,13:45
By the i915 driver, I meant the kernel module not the driver in xorg.Using XFree, I get drm on a 855GM with the i810 driver and the i830 & drm kernel modules loaded. Using xorg-7.2 and DSL with the i810 driver and the i830 & drm kernel modules, I get an error message stating drm will not work with the i830. In DSL-N with the i810 driver and i915 & drm kernel modules, I get an error message that the i915 version is too old. The good news in all this is that I no longer have to use i855wrap to sort out the video ram, xorg-7.2 takes care of it.
The Intel drivers in xorg-7.2 are:
/opt/xorg72/lib/xorg/modules/drivers/i128_drv.so, i740_drv.so & i810_drv.so
I believe you would still use the i810 driver for your chipset. I'm looking to compile i915 & drm kernel modules against 2.4.26 & 2.6.12 as per < this post > but first I have to get git to work...
Posted by WDef on June 30 2007,17:13
Trying to recall what I did several years ago to get DRI drivers on Fedora Core 4 going so that I had acceleration and dri for the 915GM chipset (no longer needed with FC5+ apparently, these must now be included).After updating Xorg to 6.9 I downloaded the common, i810, and i915 tarballs from somewhere (and compiled?) and installed those. I know it wasn't git. And yes, xorg.conf gets pointed at i810 with drm getting loaded in the 'modules' section. I had prepared kernel sources. They have precompiled snaphots available but these are no longer updated - last one March 2006. I think those are what I probably must have used.
The snapshot tarball chosen has to match the particular graphics card.
< http://dri.freedesktop.org/wiki/Download >
| Quote |
| Nightly snapshots of the DRI drivers for Linux are available from < http://dri.freedesktop.org/snapshots/. > You need to download and install the correct snapshot for your graphics card and a "common" snapshot in order to get all new DRI features. The "common" snapshot does not need to be updated as frequently as the card-specific snapshot. Note: If you are using a radeon 8500 or higher (8500, 8700, 9000, 9100, 9200, IGP9100, etc.) choose the r200 shapshot, otherwise choose radeon (7000, 7200, 7500, IGP320, IGP340, etc.). Note: If you have a i830/45/55 graphics chip you now need the i915 snapshot. The i830 driver is deprecated and no new snapshots are produced for it. |
Posted by curaga on July 01 2007,05:52
With Xorg 6.9 I used kernel driver i830 and Xorg driver i810..And with 7.2 changed to i915 but Xorg driver is still i810..
My chip is 830M and I had DRI working with both cases (compiled Xorg myself in both cases)
News from the intel front: which intel driver for Xorg you used? Which version does it show in Xorg.log.0?
As the default one, 1.6.5 has a bug of giving errors "not able to allocate memory" even though it can. The current one for 7.2 is 1.7.4 I think (using it now) but the new 2.0 series could also be used.
In the 2.0 series Xorg driver is renamed "intel" (but has a symlink from i810) and it no longer depends on video bios (fully programmable video modes on i830M and up) and has improved hot-plug monitor detection..
Posted by curaga on July 01 2007,05:56
..um, where di Hats find this? It isn't on Ibiblio or Belnet yet..
Posted by Juanito on July 01 2007,06:07
| Quote |
| ..um, where di Hats find this? It isn't on Ibiblio or Belnet yet.. |
The cd is still in the mail to Roberts, I sent ^hats^ the file via ftp.
Maybe you could post your i915 (and associated drm) kernel modules to the repository "modules" section so I can try it/them out?
Posted by curaga on July 01 2007,06:09
Nope, they are compiled in in a 2.6.20.14 kernel..edit: Forgot to mention again. This is on my distro, I haven't compiled Xorg on DSL at all.. Or anything that big.
Could you check the i810 driver version?
Posted by WDef on July 02 2007,14:37
| Quote |
| nd with 7.2 changed to i915 but Xorg driver is still i810.. My chip is 830M and I had DRI working with both cases (compiled Xorg myself in both case |
Are you saying that i915 / DRI is included in Xorg7.2 and there's no longer any need to compile these seperately? I thought this might be the case?
EDIT: To answer my own question - Google says a DRI capable driver has been included in Xorg since version 7. So there should be things like r300_dri.so, i915_dri.so etc in Juanito's equivalent of /usr/X11R6/lib/modules/dri/ or /usr/lib/dri
That might also explain why there's no updates to snapshots on the dri website, although was not there also some patent problem or something ...
Posted by Juanito on July 02 2007,17:17
In order to compile xorg-7.2, I had to compile mesa-6.5.2 and yes, this compile produces i915_dri.so (19MB...), r300_dri.so, etc in /usr/lib/modules/dri.The compile options for xorg required it to be given the location of the mesa source files but it did not appear to use these dri files and they are not included in my extension - my understanding is that mesa uses these drivers when it is run without xorg but I could easily be mistaken.
BTW, I am still trying to compile the i915 kernel module - I'm almost there with DSL-N but the common and i915 snapshots handily don't include a script that the install script requires. With DSL, it appears that the kernel needs to be recompiled with CONFIG_X86_CMPXCHG set in order for i915 to compile [sigh]
Posted by WDef on July 02 2007,20:05
Sorry, I get it now - i915 and drm are both kernel modules that are included with 2.6.xx kernels beyond a certain version. That's why I no longer have to compile the dri snapshots on fedora.But not so with i915 for the 2.4.26 kernel.
While googling I found a 2005 post that said the old i915 driver from the Intel site worked on 2.4.xx kernels but the freedesktop.org dri sources did not compile. Perhaps there's an archive somewhere of old Intel dri driver sources?
Posted by Juanito on July 03 2007,03:45
| Quote |
| a 2005 post that said the old i915 driver from the Intel site worked on 2.4.xx kernels |
I believe I saw that post - the problem is that xorg72 rejects the i915 kernel module in DSL-N/2.6.12 as being too old, so I believe the same thing would happen with the old Intel version on 2.4.26
Posted by ^thehatsrule^ on July 03 2007,04:35
Trying to use Xorg -configure| Code Sample |
| /opt/xorg72/bin/Xorg: relocation error: /opt/xorg72/lib/xorg/modules/drivers//sunffb_drv.so: undefined symbol: xf86MatchSbusInstances |
Thread from < http://lists.freedesktop.org/archives/xorg/2006-March/013454.html > suggests that sun* stuff doesn't need to be built at all... but since you probably don't want to recompile, removing /opt/xorg72/lib/xorg/modules/drivers/sun* should be sufficient (there's also some config template stuff in .../lib/X11/config/sun* which should be safe to remove as well). Saves a bit of space.
Now you can
| Code Sample |
| # .../bin/Xorg -configure # cp /root/xorg.conf.new /etc/X11/xorg.conf |
Also tried xorgcfg - won't run due to missing libxkbui.so.1 - this supposedly runs Xorg -configure, X, then tweaks it. If certain libs aren't going to be included by default, perhaps removing the binaries that depend on them might save quite a bit of space. Currently .../bin is almost 155M.
More info here: < http://wiki.x.org/wiki/ConfigurationHelp >. Seems to suggest the use of xorgcfg or minimally X -configure. Probably using xorgcfg will be the best though...
Posted by Juanito on July 03 2007,06:01
I did not see the error about sunffb_drv.so when I tried -configure but I also got /dev/input/mice detected instead of /dev/psaux.Like xorgconfig, I must have tried xorgcfg on the previous 187MB iteration of the extension because libxkbui.so.1 is present in that.
I believe my mistake was to go to < http://wiki.x.org/wiki/ModuleDescriptions?highlight=%28xprint%29 > and take out most stuff that wasn't "Core X11 runtime" without thinking hard enough about it.
Posted by curaga on July 03 2007,14:32
Hey Juanito, didn't you strip at all? 30mb left at once with strip -g /opt/xorg72/lib/*so*
Posted by curaga on July 03 2007,14:43
I'm stripping it right now.. I'll see how small it'll get..
Posted by curaga on July 03 2007,15:01
I found a weird symlink: /opt/xorg72/lib/libdrm.so.1 points to /mnt/sdb4/opt/xorg72/lib/libdrm.so.2.3.0I'll fix that..
Posted by curaga on July 03 2007,15:41
I'm shocked you didn't strip at all, there was nearly 200mb in debug symbols!I also removed Xnest, Xdmx, some fonts not necessary, and the size: 175 -> 27mb!
Should I post this?
Posted by Juanito on July 03 2007,18:39
I'd honestly never heard of the strip command/function/whatever (or debug symbols) but, yes please post.I'll look at adding the xorgconfig functionality later
Posted by ^thehatsrule^ on July 03 2007,23:08
Wow, I never thought it was a debug compilation by default... should have thought of that!Thought that that behaviour was default only if you grabbed the code from the dev tree. Here's a thread: < http://lists.freedesktop.org/archives/xorg/2006-February/013414.html > Perhaps you can also do the same with the build-from-tarballs script.
Typically debug stuff is useful for developers and testing, i.e. bug reports, etc. whereas production code doesn't need this at all.
I don't think sun hardware would be used at all, so it's probably better to remove it anyways but I could be wrong... I'll try it again later. There's also some interesting minimal configurations from here: < http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml >
Posted by curaga on July 04 2007,09:00
I removed sun drivers too to lessen problemsDebug symbols are always compiled in (so that if it crashes, it prints the function name not just numbers or something like that). The -g switch, which most configures add, increases them notably, and if you replace that with -s, they are stripped during compilation..
Posted by Juanito on July 06 2007,11:55
I tried out the stripped extensions from ^hats^ and curaga - thanks for taking an interest - and found the following:curaga's extension - I could only run x as root. At first I thought that this was due to the symlink /opt/xorg72/var/log -> /var/log being root/ssl-something instead of root/staff but I am not sure if this would require running as root. Where I would normally get error messages about dri/drm in the xorg log (due to the i915 kernel module being too old), I did not get any errors but there was no sign of dri/drm loading - maybe this functionality was stripped out?
^hats^ extension - seemed to work OK and xorgconfig worked. I assume you must have stripped my larger extension if this functionality worked?
Posted by curaga on July 06 2007,12:17
I've no idea how that happened. I didn't touch anything except fonts, helloworld programs, sun drivers, that weird symlink and debug symbols..
Posted by Juanito on July 08 2007,15:40
Still trying to compile a newer i915 kernel module to test things properly - am I missing something here:| Code Sample |
| $ sudo git clone git://anongit.freedesktop.org/git/mesa/drm ... git: fatal error: `chdir' failed: permission denied |
Posted by ^thehatsrule^ on July 08 2007,17:45
| Quote |
| seemed to work OK and xorgconfig worked. I assume you must have stripped my larger extension if this functionality worked? |
| Quote |
| git: fatal error: `chdir' failed: permission denied |
Posted by Juanito on July 08 2007,18:01
| Quote |
| I suppose in addition to the test apps that could be taken out, this could be considered the "starting" point to take out even more things... |
I think it's important (or at least useful) to leave in xorgconfig and certainly 47MB makes a better starting point than 175MB+ Perhaps you could pass the extension to Roberts to replace my original?
| Quote |
| From searching the web, it seems to be a problem of invoking the outdated "gnu interactive tools" as opposed to Linus' git. |
We must have been seraching at the same time - openssl is currently compiling en route to compiling curl en route to compiling the Linus version of git...
Posted by curaga on July 08 2007,18:14
Feel free to replace mine, too - as it didn't seem to work for Juanito
Posted by Juanito on July 09 2007,03:59
| Quote |
| - as it didn't seem to work for Juanito |
Don't get me wrong, it would be very nice to have the extension slimmed down to 27MB - I just need to figure out why I need to be root to startx with the 27MB extension and why it doesn't seem to try and start drm (which, apart from eliminating the need for 855wrap, was the object of the exercise for me).
Posted by Juanito on July 13 2007,13:34
It took a while, but I finally got around to compiling git and downloaded the drm sources:git clone git://anongit.freedesktop.org/git/mesa/drm
For the moment, I tried compiling the module with DSL-N (it looks like the kernel would need recompiling in DSL) - unfortunately, compiling the i915 module comes up with the following error in the drm module and consequently neither drm nor i915 will load:
*** Warning: "idr_replace" [/usr/src/drm/linux-core/drm.ko] undefined!
There are plenty of hits in Google for this and several patches - none of which seems to fix the problem.
WDef - I recall you have Intel graphics, did you ever try compiling i915 to get drm working with xorg? Without this it is kind of hard to test drm with Curaga or ^hats^ versions of xorg72...
Posted by ^thehatsrule^ on July 13 2007,14:37
What's the kernel in DSL-N rc4... 2.6.12? Seems like idr_replace was around 2.6.16 as a patch... officially in the main kernel tree as of 2.6.18Is there a flag you can set for the kernel target?
EDIT:
In drm git:
First instance of idr_replace: < http://gitweb.freedesktop.org/?p=mesa....17042f7 >
So you could get a release that is at least 11 days old instead...
Posted by Juanito on July 13 2007,15:15
Thanks - I understand from this, that if I use git to get the drm tree prior to the first instance of idr or idr-replace, things might work.I used git for the first time today - how would I achieve the above?
[Yes, the kernel is 2.6.12 in DSL-N]
Posted by curaga on July 15 2007,07:01
Juanito: you asked in some else thread what are debug symbols, I explained that in this one but didn't tell how to get rid of 'em after compiling."strip -g lib" for libraries
"strip --strip-unneeded binary" for binaries
as libraries are nothing but symbols, only debug ones (-g aka --strip-debug) need to go.
binaries have some relocation info too that is not needed.
Posted by stupid_idiot on July 15 2007,13:33
(Sorry, bad post. Should be deleted.)
Posted by ^thehatsrule^ on July 17 2007,06:09
Juanito:I've only used git-clone ...
On another note, did you use the security patches/fixes on xorg 7.2 ? If not, perhaps we can just build those outstanding packages... see < http://www.x.org/wiki/SecurityPage >
Posted by curaga on July 17 2007,08:26
Another note: could you build the Xserver package again, this time specifying --with-kdrive (not sure if that's the one, check with configure --help)?As tiny X isn't built by default, and Xorg 7.2 included some new ones compared to Xfree 4.6, you could then post the Tiny X servers that weren't in Xfree..
Posted by Juanito on July 20 2007,07:02
| Quote |
| On another note, did you use the security patches/fixes on xorg 7.2 ? |
| Quote |
| Another note: could you build the Xserver package again, this time specifying --with-kdrive |
Posted by curaga on July 20 2007,08:00
Not the full Xorg! Just Xserver, manually... It will only take a couple of hours...
Posted by Juanito on Sep. 30 2007,09:57
OK, it's been more than a week but here goes:| Code Sample |
| $ mydsl-load xorg72.tar.gz $ mydsl-load xorg/xorg72-dev.tar.gz $ export LDFLAGS=-L/opt/xorg72/lib $ export CFLAGS=-I/opt/xorg72/include $ export PKG_CONFIG_PATH=/opt/xorg72/lib/pkgconfig $ cd /usr/src/libdrm-2.3.0 $ ./configure --prefix=/opt/xorg72 $ make $ sudo make install $ cd /usr/src/xorg-server-1.2.0 $ ./configure --prefix=/opt/xorg72 --enable-kdrive |
There's no errors in config and it mentions preparing the make file for several kdrives, but then:
| Code Sample |
| $ make ... Making all in dri ... gcc: cannot specify -o with -c or -S and multiple compilations make[4]: *** [libdri_la-dri.lo] Error 1 make[4]: Leaving directory `/ramdisk/usr/src/xorg-server-1.2.0/hw/xfree86/dri' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/ramdisk/usr/src/xorg-server-1.2.0/hw/xfree86' make[2]: *** [all] Error 2 make[2]: Leaving directory `/ramdisk/usr/src/xorg-server-1.2.0/hw/xfree86' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/ramdisk/usr/src/xorg-server-1.2.0/hw' make: *** [all-recursive] Error 1 |
Any ideas? The version of gcc maybe?
Posted by jpeters on Sep. 30 2007,16:20
| Quote (Juanito @ Sep. 30 2007,05:57) |
| gcc: cannot specify -o with -c or -S and multiple compilations |
I asked about this also: < http://damnsmalllinux.org/cgi-bin....t=19132 >
This seems to be a bug in gcc; mismatches with headers??
Posted by curaga on Sep. 30 2007,16:22
Well, it's a gcc error
Posted by Juanito on Oct. 01 2007,12:40
Weirdly, I didn't get the gcc error the second time I tried - after adding the headers/libs from mesa-6.5.2, the kdrives apparently compiled.I have:
| Code Sample |
| $ ls /mnt/sdb1/source/xorg/kdrive Xati Xephyr Xfake Xi810 Xmga Xnvidia Xr128 Xvesa Xchips Xepson Xfbdev Xmach64 Xneomagic Xpm2 Xsmi Xvia |
I can probably test Xi810 (video memory issues permitting) and Xmga. Do the kdrives accept the same arguments as the default dsl Xvesa? Is there any trick to testing them?
Posted by curaga on Oct. 01 2007,17:56
If you don't have the chipset, you can't start them. Believe me, I tried I think the newer ones accept more options than DSL's Xvesa. And they got even more updates in Xorg 7.3, with hot-plugging monitors and stuff ;)
Xfake probably ain't needed, what do you think?
How are the sizes compared to mine & do they all work on plain DSL? Just wondering if they'd be a good replacement for my versions too..
Posted by chaostic on Oct. 03 2007,17:31
If those TinyX servers are anything like the ones currently in the repository (i.e., no extra dependencies outside of the mydsl package it is in), pack it up and send me the xati to test. I have both a thinclient with an ATI Radeon 7000m and a desktop with ATI Radeon 9800. Xvesa too if it allows for changing the display frequency. Oh and xfbdev and xvia, as Im picking up some more thinclients with them.
Posted by curaga on Oct. 03 2007,18:40
I thought the ones currently in mydsl can already change the refresh rate?
Posted by chaostic on Oct. 03 2007,22:13
| Quote (curaga @ Oct. 03 2007,14:40) |
| I thought the ones currently in mydsl can already change the refresh rate? |
Ha. Probably, but I want to test the Xati one first, since I would get most use out of it.
Posted by Juanito on Oct. 04 2007,03:47
So far the testing is not going that great:| Code Sample |
| $ /mnt/sdb1/source/xorg/kdrive/Xi810 -mouse /dev/psaux,5 -screen 1024x768x24 -nolisten tcp no matching card found Fatal server error: Linux Init: Server must be suid root [with a PCI:*(0:2:0) Intel Corp. 82852/855GM Integrated Graphics Device rev 2] $ ls -l /mnt/sdb1/source/xorg/kdrive/Xi810 -rwsrwxr-x 1 root root $ $ /mnt/sdb1/source/xorg/kdrive/Xvesa -mouse /dev/psaux,5 -screen 1024x768x24 -nolisten tcp Fatal server error: Linux Init: Server must be suid root |
Posted by curaga on Oct. 04 2007,14:48
Is your sdb1 mounted nosuid?
Posted by Juanito on Oct. 04 2007,14:58
If this is how you check for that, then:| Code Sample |
| $ cat /etc/fstab | grep sdb1 /dev/sdb1 /mnt/sdb1 ext2 noauto,users,exec 0 0 |
Posted by curaga on Oct. 04 2007,15:57
Try setting it to setgid root too..
Posted by ^thehatsrule^ on Oct. 04 2007,16:18
Could be related to the same problem before (i.e. symlinking build dir to hd). Try running it off somewhere on /ramdisk ?Also, what happens if you try to run it with root privileges?
Posted by Juanito on Oct. 04 2007,17:12
| Quote |
| Try setting it to setgid root too.. |
- does the drive have an effect on this, if the file is set suid & guid root?
| Quote |
| Could be related to the same problem before (i.e. symlinking build dir to hd). Try running it off somewhere on /ramdisk ? |
- this was built on /ramdisk against the xorg72 extension and headers. I'll copy it to /opt/xorg72/bin and try again. Since sudo make install did not copy the kdrives, it is possible make did not set the correct permissions.
| Quote |
| Also, what happens if you try to run it with root privileges? |
- I couldn't do this as I was using LD_LIBRARY_PATH to point to the xorg72 libs (the kdrive needs libXfont.so.1, not in base dsl).
Edit:
I tried this on another machine:
| Code Sample |
| $ exec /opt/xorg72/bin/Xmga -3button -mouse /dev/psaux -screen 1280x1024x16 -nolisten tcp Fatal server error - no matching cards found $ lspci | grep Matrox 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] AGP [This required libs libXfont.so.1, libXau.so.6, libfontenc.so.1, libxdmcp.so.6] |
and:
| Code Sample |
| $ exec /opt/xorg72/bin/Xvesa -3button -mouse /dev/psaux -screen 1280x1024x16 -nolisten tcp Error cannot find /opt/xorg72/lib/xserver/security.policy various font errors fixed font error |
Thus it would seem the kdrives require additional libs vs the base dsl and they need to be compiled with the same prefix as the original Xvesa kdrive and they don't seem to recognise i810 and mga video cards.
Does it make sense to carry on?
Edit2:
I tried Curaga's Xvesa extension - this started a grey screen with just the cursor. After exiting, there were various "could not init font" errors.
Posted by chaostic on Oct. 06 2007,05:03
Yes, carry on please 
Posted by curaga on Oct. 06 2007,14:37
I feared that your's would be linked to Mesa..