Tiny Core Linux
Tiny Core Extensions => TCE News => TCE 3.x => Topic started by: curaga on June 06, 2010, 10:24:57 AM
-
Xorg 7.5 now available!
Highlights from 7.4 include new hardware support, such as Nvidia ION, and 3d support for Radeon r600/r700.
With this modularized release, pick either Xorg-7.5.tcz or Xorg-7.5-3d.tcz and all deps shall be gotten for you (with the possible exception of firmware; Radeon 3d requires the firmware.tcz extension, for example).
Minimum requirement is 3.0alpha5.
Title: Xorg-7.5-3d.tcz
Description: Accelerated 3d drivers
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 12.8M
Extension_by: Curaga
Comments: If you want Xorg with 3d, this extension is all you
need.
Change-log:
Current: 2010/05/28 Original
Title: Xorg-7.5-bin.tcz
Description: Binaries from Xorg
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 304.0K
Extension_by: Curaga
Comments: All binaries from Xorg that don't have dependencies.
Change-log:
Current: 2010/05/28 Original
Title: Xorg-7.5-dev.tcz
Description: X development files
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 1.8M
Extension_by: Curaga
Comments:
Change-log:
Current: 2010/06/01 Original
Title: Xorg-7.5-lib.tcz
Description: Xorg 7.5 libraries
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 176.0K
Extension_by: Curaga
Comments: This extension supercedes Xlibs_support.tcz.
Change-log:
Current: 2010/05/28 Original
Title: Xorg-7.5.tcz
Description: X.org server
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 9.8M
Extension_by: Curaga
Comments: To run confless, restart X after loading the extension.
If you need to configure something, such as a keymap, or
have trouble with autodetection, create a xorg.conf.
.
If you are only looking to get software 3D
and no accel, instead of creating a config file
suitable for your hardware like below, you can rename
/etc/X11/xorg.conf.vesa to xorg.conf.
.
To get Xorg with accel, exit to prompt,
get a root console (sudo su), and then
Xorg -configure
.
Edit the newly created config file as needed.
When ready copy it to /etc/X11 named xorg.conf.
Remember to add this file to your backup (/opt/.filetool.lst)
or save it some other way.
.
See Xorg-7.5-3d.tcz for acceleration.
.
Please note, for AGP or integrated AGP cards such as Intel
chips you will always need graphics-KERNEL.tcz.
.
Tips on 3D and X keymaps can be found in
/etc/X11/README.xorg.conf.
Change-log:
Current: 2010/05/28 Original
The following two drivers are separate, because they hang/segfault X -configure. If you need either one, it needs to be grabbed separately.
Title: Xorg-7.5-vmware.tcz
Description: VMWare Xorg driver
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 28K
Extension_by: Curaga
Comments:
Change-log:
Current: 2010/05/31 Original
Title: Xorg-7.5-xgi.tcz
Description: XGI (/XP) Xorg driver
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 164K
Extension_by: Curaga
Comments:
Change-log:
Current: 2010/05/31 Original
-
Right. Just a quick 1-for-1 replacement didn't work - it failed to start. Had a quick sniff around but haven't found anything obvious yet.
-
Log & dmesg? Also, if this is an Intel chip, remember to remove all "nomodeset", "modeset=0" etc params, Intel on 7.5 requires KMS.
-
are you planning to adjust all dep files ?
Xorg-7.4 --> Xorg-7.5
Xorg-7.4-dev --> Xorg-7.5-dev
Xlibs_support --> Xorg-7.5-lib
-
Thanks, just back from the garage working on my bicycle; saw your nomodeset tip and it worked. Thanks!
-
are you planning to adjust all dep files ?
Xorg-7.4 --> Xorg-7.5
Xorg-7.4-dev --> Xorg-7.5-dev
Xlibs_support --> Xorg-7.5-lib
Only the last two, after a couple of days. For the first one, as extensions are rebuilt against 7.5 the makers can adjust the deps.
-
Only the last two, after a couple of days. For the first one, as extensions are rebuilt against 7.5 the makers can adjust the deps.
is rebuilding really needed ? i have tested a few extensions no problem so far, extensions tested are :
nvidia-glx, dreamchess, gnome-desktop-base
edit: more tests: compiz-base, compiz-gnome, all ok
-
Possibly not, but instead of forcing the change it's better to let it come naturally. Also lessening some deps, if 3d is not necessary Xorg-7.5-lib might be enough.
At least the Nvidia driver should be rebuilt, for as a Xorg driver running against a different server might cause undefined behavior.
edit: or you could have one for 7.4 and one for 7.5, as both can be used in 3.x.
-
nvidia has no source to build except kernel interface layer
why not just convert everything and only rebuild extensions that really needs it ?
otherwise one may mess up with Xorg-7.4 and Xorg-7.5 installed at the same time :)
btw i have Xorg-7.5 and nvidia-glx installed but i didn't load Xorg-7.5-3d, what is really in it, some open source drivers ?
-
There were applications, like Google Earth did not work with Xorg 7.4 on Intel Graphic chips, 915, 945, ...
With Xorg 7.5 Google Earth is running fine with 945 on my notebook. Great ! :-*
-
nvidia has no source to build except kernel interface layer
Oh, then you could just remove Xorg from the dep file and tell to pick either version in the info.
why not just convert everything and only rebuild extensions that really needs it ?
We don't know which they are, it's better for the extension maintainers to handle it.
otherwise one may mess up with Xorg-7.4 and Xorg-7.5 installed at the same time :)
btw i have Xorg-7.5 and nvidia-glx installed but i didn't load Xorg-7.5-3d, what is really in it, some open source drivers ?
Yeah, the Mesa drivers.
-
Might be good to do something about all the extensions that have Xorg-7.4 as dep, to either duplicate them temporarily with Xorg-7.5, or perhaps to list them somewhere so users can edit the dep files after every update.
-
I'd like to add my vote to those that are proposing a more "brute force migration". By this I mean a bulk update of the dependency files.
I'm not saying to do it in the next 24h, but don't wait for many weeks or month with it. Because as we have seen with the long running "openssl saga" many maintainers don't care, don't know or forget about it and choose or leave the old version in the .dep files. That means the new version does not really get tested. Even freshly build extensions in that case were continuing to refer to the old version. In my view a bit a forceful approach is quite in order here. In particular as TC 3.0 is not yet declared stable I see more of a chance to break things now then at a later point in time. OTOH lets face it: TC is (at least in my view) not really meant to be as "rock-solid" as RH.
If my counting is not off there are 32 extensions in the 3.x repository that depend on Xorg-7.4.tcz directly. Add to this 10 extensions which refer to Xorg-7.4-dev.tcz. I wonder how many of those really need the "full" Xorg extension or if some could get away for example with Xorg-7.5-bin.tcz. In any case it should be really well understood what aspect of any 'Xorg' extension it is that another one needs. For example some application might "just work" with Xorg-7.5.tcz but it would have already done so with 'Xvesa', but using Xorg-7.5-3d.tcz is what really makes a difference. OTOH it's the question to which degree our .dep files should reflect "minimal requirements" or "best performance". IMHO the .dep file should only include the absolute minimum and anything else should be noted in the .info file.
I also tried to find out who are the maintainers of those 32 extensions:grep "Xorg-7.4\." *.dep | sed 's#\.dep.*##' | while read e ; do
t=$( grep 'Title' ${e}.info | tr '\t' ' ' | sed 's#.*: *##' )
m=$( grep 'Extension_by' ${e}.info | tr '\t' ' ' | sed 's#.*: *##' )
printf "%-30s%s\n" "$m" "$t"
done | sort
Althalus plt.tcz
Arslan S. cairo-clock.tcz
Arslan S. clutter.tcz
Arslan S. compiz-base.tcz
Arslan S. compiz-gnome.tcz
Arslan S. compiz.tcz
Arslan S. dreamchess.tcz
Arslan S. freeglut.tcz
Arslan S. ftgl-dev.tcz
Arslan S. ftgl.tcz
Arslan S. gnome-desktop-base.tcz
Arslan S. gtkglext.tcz
Arslan S. hedgewars.tcz
Arslan S. nvidia-glx.tcz
Arslan S. pinball.tcz
Arslan S. projectM.tcz
Arslan S. teeworlds.tcz
Arslan S. vinagre.tcz
Arslan S. vino.tcz
Curaga Mplayer-xorg.tcz
Curaga, Robert Schumann wine-gl-dev.tcz
Curaga, Robert Schumann wine-gl.tcz
Jason W kdelibs-3.5.10.tcz
SvOlli qt-4.5-opengl.tcz
SvOlli qt-4.x-opengl.tcz
bmarkus bigforth.tcz
bmarkus lxrandr.tcz
bmarkus xplanet.tcz
juanito synaptics.tcz
robc mupen64plus.tcz
robc recordmydesktop-gtk.tcz
wonderfulll xf86-video-unichrome.tcz
So a lot of the responsibility rests with just a few people. Maybe we can spread out some of the testing, but I hate to admit that I'm not a regular user of any of those so my "expertise" in helping out might be rather limited.
Furthermore trying to create new extensions to extend the usability of 'Xorg-7.4' is in my view fatal. It would only increase the confusion. I'm of the opinion that a "short & sharp" period of "pain", is much better than a "long suffering". Therefore a speedy change from Xlibs_support.tcz to Xorg-7.5-lib.tcz might be the first thing to do.
If people see the need I could try to undertake a similar analysis (based on 'ldd') as I once did for 'openssl'. I'm just worried that it might take a few days and I urgently need to send my (main) laptop into repair before the warranty runs out. That limits my ability of doing this in the short term.
If a "forceful migration" in the near future is not acceptable I'd like to propose that at least no update of any extension (and no new one) makes it into the repository that still uses Xorg-7.4.tcz (or Xlibs_support.tcz). That way the issue should at least not continue to grow over time.
-
maro thanks for the list, i was wondering how many extensions out there that depends on Xorg-7.4, i will test one by one and rebuild/update if required
my opinion is that there should not be two versions of same extension in the repository
most of the extensions which i created depends on Xorg because they are 3D applications, some games, OpenGL based libraries and a desktop which requires xkb, some Xorg executables, xrandr etc.
major version of OpenGL is same libGL.so.1 in Xorg-7.4 and Xorg-7.5
-
Arslan, I trust you are aware which executables are now available via Xorg-7.5-bin.tcz (e.g. 'xrandr' being one of them). Hence that might reduce the requirements in a disk-space friendly way.
-
Arslan, I trust you are aware which executables are now available via Xorg-7.5-bin.tcz (e.g. 'xrandr' being one of them). Hence that might reduce the requirements in a disk-space friendly way.
do you want me to remove Xorg dependecy from gnome desktop ? or did i misunderstand ?
-
The first updates are done, Xorg-7.4-dev and Xlibs_support in dep files have been replaced.
Also thanks for maro's list, Mplayer-xorg's dep file edited, and xf86-video-unichrome removed from the 3.x repo (same or newer version is a part of 7.5, and it was built against 7.4).
-
Arslan: In the end it's the maintainers call. And clearly trying to save a few MBytes when anything Gnome has a dependency list from "here to Rome" is pointless. So you better ignore my reply #15. I just thought more generally not to simply replace "7.4" with "7.5" but consider what is really required (in case of a "non-gigantic" extension).
I'm now curious enough so that I might try tomorrow to install (for the very first time) 'gnome-desktop-base.tcz' in a VBox VM (running TC 3.0a6).
-
I see a serious drop in Youtube performance in full screen mode:
- with xorg 7.4 I get acceptable video: estimate 15 frames per second or so
- with Xorg 7.5 I get very slow video: estimated framerate 3-4 per second
I remember that in the early days of Tinycore full screen Youtube performance was similarly bad, but from a certain version the problem disappeared. Don't remember which version.
Except for the Xorgs the systems are identical with the same Xorg.conf.
Xorg -configure does not help
I see nothing suspicious in the Xorg.0.log files
-
Just curious, is there any difference with the 3D extension installed?
-
First of all, thanks for including the VMware mouse driver. But is there any cause, why the VMware graphics drivers have been left out?
BTW: I'm just on updating the qt-4.x-* packages to compile and link against Xorg-7.5, the qt-4.5-* packages are just copied from the TCL-2.x repository and should be removed asap.
-
I see a serious drop in Youtube performance in full screen mode:
- with xorg 7.4 I get acceptable video: estimate 15 frames per second or so
- with Xorg 7.5 I get very slow video: estimated framerate 3-4 per second
I remember that in the early days of Tinycore full screen Youtube performance was similarly bad, but from a certain version the problem disappeared. Don't remember which version.
Except for the Xorgs the systems are identical with the same Xorg.conf.
Xorg -configure does not help
I see nothing suspicious in the Xorg.0.log files
Check your dmesg, as well as post both dmesg and Xorg.0.log.
First of all, thanks for including the VMware mouse driver. But is there any cause, why the VMware graphics drivers have been left out?
BTW: I'm just on updating the qt-4.x-* packages to compile and link against Xorg-7.5, the qt-4.5-* packages are just copied from the TCL-2.x repository and should be removed asap.
Mentioned in the first post:
The following two drivers are separate, because they hang/segfault X -configure. If you need either one, it needs to be grabbed separately.
Quote
Title: Xorg-7.5-vmware.tcz
-
In the Xorg-7.5-vmware package the 3D support seems to be missing. The vmwfgx_drv.so and vmwgfx_dri.so drivers are not in the archive. I managed to take them from the vmware-tools-distrib package, but there seems to at least one more peace missing:
[...]
(II) Module vmwgfx: vendor="X.Org Foundation"
compiled for 1.7.4, module version = 11.0.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
[drm] failed to load kernel module "vmwgfx"
(--) vmware: Please ignore above "[drm] failed to load kernel module "vmwgfx""
(II) vmware: Using vmwlegacy driver everything is fine.
[...]
Hmmm... claiming that with using a fallback solution "everything is fine"... :(
The host machine I'm trying right now does not support VMware 3D. Could this be the cause? I'll give it a try on another machine tomorrow.
-
@curaga: Did you think about applying the mesa-7.1-link-shared.patch as it is used for example in Fedora? It reduces the size of the mesa modules extremely by extracting most of the code into a shared libdricore.so, some time ago I already managed to do that on my own for Xorg-7.5, so it's at least possible IMHO...
Fedora example:
$ ls -l /usr/lib64/dri/
-rwxr-xr-x. 1 root root 515920 2. Mar 06:04 i915_dri.so
-rwxr-xr-x. 1 root root 563152 2. Mar 06:04 i965_dri.so
-rwxr-xr-x. 1 root root 2163544 2. Mar 06:04 libdricore.so
-rwxr-xr-x. 1 root root 305424 2. Mar 06:04 mga_dri.so
-rwxr-xr-x. 1 root root 212336 2. Mar 06:04 r128_dri.so
-rwxr-xr-x. 1 root root 410440 2. Mar 06:04 r200_dri.so
-rwxr-xr-x. 1 root root 396344 2. Mar 06:04 r300_dri.so
-rwxr-xr-x. 1 root root 341320 2. Mar 06:04 r600_dri.so
-rwxr-xr-x. 1 root root 371400 2. Mar 06:04 radeon_dri.so
-rwxr-xr-x. 1 root root 245088 2. Mar 06:04 savage_dri.so
-rwxr-xr-x. 1 root root 49008 2. Mar 06:04 swrast_dri.so
-rwxr-xr-x. 1 root root 284784 2. Mar 06:04 tdfx_dri.so
-rwxr-xr-x. 1 root root 228064 2. Mar 06:04 unichrome_dri.so
$ du -h /usr/lib64/dri
5,9M /usr/lib64/dri
[edit]Added patch to attachment ;-)[/edit]
best regards,
robert
-
Check your dmesg, as well as post both dmesg and Xorg.0.log
Here are the requested files
- dmesg when running alpha6 with Xorg 7.4
- dmesg when running alpha6 with Xorg 7.5
- Xorg.0.log when running alpha6 with Xorg 7.4
- Xorg.0.log when running alpha6 with Xorg 7.5
I reverified the playback speed difference: it's still there and very noticeable
The installed 7.5 version is Xorg-7.5-3d
-
@SvOlli:
The vmwgfx/svga drivers in both kernel and mesa are currently named as unstable, and recommended against using in production environments. They default to off in all three parts (those plus libdrm).
@gutmensch:
Didn't know of that. What's the upstream status?
-
@curaga:
The attached patch is from mesa 7.7, I extracted it from the fedora source package "mesa-7.7-4.fc12.src.rpm"... I think I used that one too when I tried mesa 7.7 for Xorg 7.5 last time.
-
I reverified the playback speed difference: it's still there and very noticeable
The installed 7.5 version is Xorg-7.5-3d
Are you sure your 7.4 install wasn't using Nvidia's binary drivers at some point? There hasn't ever been real acceleration in nv.
There doesn't seem to be an extension for the 96 series drivers for 3.x yet though.
-
I haven't consciously installed any additional video drivers.
The Xorg-7.4 extension used is the official unmodied Tiny Core one.
The Xorg version difference is the only one between the two systems I compare. All other extensions are exactly the same.
-
Then I can't say why you ever got good performance; Adobe Flash uses either opengl or no accel, and all 3d with nv is software.
-
you can run glxgears and compare your fps results
-
About Xorg-7.5-vmware again:
I gathered together all the files necessary to get 3D up and running inside VMware, up 'til now, these are:etc/X11/xorg.conf
usr/local/lib/X11/modules/libexa.so
usr/local/lib/X11/modules/dri/vmwgfx_dri.so
usr/local/lib/X11/modules/drivers/vmwlegacy_drv.so
usr/local/lib/X11/modules/drivers/vmware_drv.so
usr/local/lib/X11/modules/drivers/vmwgfx_drv.so
usr/local/lib/modules/2.6.33.3-tinycore/kernel/drivers/gpu/drm/vmwgfx/vmwgfx.ko
The kernel module is self compiled, the rest are binaries taken from the VMwareTools-8.4.2-261024.tar.gz provided with VMware-Workstation-7.1.0, as well as the source for the kernel module. Now I get the error message:Fatal server error:
Could not init resource management (!pipe_screen && !libkms)
Any ideas how to fix that?
-
Sorry, no, but libkms comes from libdrm, so I guess you're missing that piece (libdrm vmware part?). Outside of that I'm not sure how version-compatible the binaries are.
-
After suspend to RAM, resume no longer works with Xorg-7.5. It crashes and freezes the PC. Xvesa and Xorg-7.4 have no problems.
Because of this, I am not sure I can give you any log files as they are all lost on rebooting.
-
I see the same thing - I played around to get syslog messages and Xorg.0.log to persist across the failed suspend/restore, but almost nothing is written to the logs and none of it is useful.
-
This time I started acpid prior to "startx".
After suspend/resume - I get: acpid: client 2186[0:50] has disconnected
..which is somehow an improvement, because the screen stayed blank without acpid (but a hard reboot is still required)
Edit: If I exit to the prompt before suspending, then things work OK and Xorg-7.5 will start again without problems.
-
I get
render error detected, EIR: 0x00000010
page table error
PGTBL_ER:0x00000001
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detected, EIR: 0x00000010
page table error
PGTBL_ER:0x00000001
But mu power button still works, I can press it and it will shut down, I don't hve to hold it in for 5s. Ctrl-alt-bksp or ctroil-alt-del don't work, so I don't know if the power button activates some bios command, or my acpid files.
-
Updated Xorg-7.5{,-lib} due to the libEGL move. Also edited qt-4.x-base.tcz.dep to depend on -lib.
Title: Xorg-7.5-lib.tcz
Description: Xorg 7.5 libraries
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 200K
Extension_by: Curaga
Comments: This extension supercedes Xlibs_support.tcz.
Change-log: 2010/05/28 Original
Current: 2010/06/16 Moved libEGL over
Title: Xorg-7.5.tcz
Description: X.org server
Version: 7.5 (1.7.7)
Author: Various
Original-site: http://x.org
Copying-policy: X11
Size: 9.8M
Extension_by: Curaga
Comments: To run confless, restart X after loading the extension.
If you need to configure something, such as a keymap, or
have trouble with autodetection, create a xorg.conf.
.
If you are only looking to get software 3D
and no accel, instead of creating a config file
suitable for your hardware like below, you can rename
/etc/X11/xorg.conf.vesa to xorg.conf.
.
To get Xorg with accel, exit to prompt,
get a root console (sudo su), and then
Xorg -configure
.
Edit the newly created config file as needed.
When ready copy it to /etc/X11 named xorg.conf.
Remember to add this file to your backup (/opt/.filetool.lst)
or save it some other way.
.
See Xorg-7.5-3d.tcz for acceleration.
.
Please note, for AGP or integrated AGP cards such as Intel
chips you will always need graphics-KERNEL.tcz.
.
Tips on 3D and X keymaps can be found in
/etc/X11/README.xorg.conf.
Change-log: 2010/05/28 Original
Current: 2010/06/16 Moved libEGL to -lib
-
I have now done a small exercise to find out if there are any other shared libraries that might qualify for being moved from Xorg-7.5.tcz into Xorg-7.5-lib.tcz. I know I should have done this a couple of days earlier but maybe it's still not too late for consideration.
The guiding principle was that any candidate has no other dependency than the ones already in Core. I therefore ran the attached script on a "plain" TC 3.0alpha7 system with the following result: link: /usr/local/lib/libdmx.so -> libdmx.so.1.0.0
link: /usr/local/lib/libdmx.so.1 -> libdmx.so.1.0.0
file: /usr/local/lib/libdmx.so.1.0.0
link: /usr/local/lib/libdrm.so -> libdrm.so.2.4.0
link: /usr/local/lib/libdrm.so.2 -> libdrm.so.2.4.0
file: /usr/local/lib/libdrm.so.2.4.0
link: /usr/local/lib/libkms.so -> libkms.so.1.0.0
link: /usr/local/lib/libkms.so.1 -> libkms.so.1.0.0
file: /usr/local/lib/libkms.so.1.0.0
link: /usr/local/lib/libpciaccess.so -> libpciaccess.so.0.10.8
link: /usr/local/lib/libpciaccess.so.0 -> libpciaccess.so.0.10.8
file: /usr/local/lib/libpciaccess.so.0.10.8
So that would be four more files (plus respective soft links) with a total of ca. 90 kBytes (uncompressed).
I'm not in a position to judge whether moving those files makes sense. It just appears from a pure "ldd-mechanics" point of view to be at least a possibility. If the "libdrm.so*" library is moved it probably would be appropriate to include "libdrm_intel.so*" and "libdrm_radeon.so*" as well.
If my way of counting is not too much off I guess that would leave just four more shared libraries in the 'lib' directory of Xorg-7.5.tcz: 'libGL.so*", 'libGLU.so*", 'libGLw.so*", and "libglut.so*". I'm not quite sure how the latter relates to the freeglut.tcz extension, but the the other three are AFAIK related to Mesa. I have the distinct impression that 'libGL.so*' is the "main culprit" why certain extensions are requiring the "full Xorg" (without needing the Xorg X server as such). I believe that 'Mplayer-xorg.tcz' is an example of such a case and have successfully tested that theory.
I guess as long as no accelerated graphics are required (which IIRC is the case for some games) just having those "GL" libraries should be sufficient to work with 'Xvesa'. I therefore wonder if it would make sense to cut one more extension out of Xorg-7.5.tcz (e.g. 'Xorg-7.5-mesa.tcz'). Obviously there would then be a chain of dependencies (i.e. Xorg-7.5 -> Xorg-7.5-mesa -> Xorg-7.5-lib), but that does not look too daunting to me.
-
The distinction on what went to -lib and what was in the main ext was the accelerated graphics.
Having libGL available with Xvesa is of no use, not even software accel that way. Mplayer-xorg's edge is the GL output, which also requires the Xorg server.
Building Mesa in such a way to work just as libGL, without the GLX extension and the swrast DRI driver, is possible, but has to be done separately. Not worth it IMO, the software renderer is very very slow. (no, a core i7 couldn't do glchess with it over 15fps)
AFAIK:
libdmx: only used by the Xdmx server & related
libpciaccess: only used by Xorg & drivers
libdrm, libkms: only used by drivers, Xephyr, libGL
I guess as long as no accelerated graphics are required (which IIRC is the case for some games) just having those "GL" libraries should be sufficient to work with 'Xvesa'.
Please point out a single game that links to GL without needing acceleration ;)
Even if they are sufficiently simple to run on the sw renderer, that isn't available with Xvesa.
-
xorg has mesa glut 3.7.1 which has not changed since 1998, and i think its license does not allow modification freeglut is to solve this problem
The original GLUT library seems to have been abandoned with the most recent version (3.7) dating back to August 1998. Its license does not allow anyone to distribute modified library code. This would be OK, if not for the fact that GLUT is getting old and really needs improvement. Also, GLUT's license is incompatible with some software distributions (e.g., XFree86).
http://freeglut.sourceforge.net/ (http://freeglut.sourceforge.net/)
-
I think that's partially old info, Mesa GLUT has been getting build and bug fixes. Though the license does not mention modification:
/* Copyright (c) Mark J. Kilgard, 1994. */
/* This program is freely distributable without licensing fees
and is provided without guarantee or warrantee expressed or
implied. This program is -not- in the public domain. */
-
Thanks guys for your responses. As you could see from my suggestion I really had not done enough research.
One of the main reasons why I like TC is the chance to create a system with a rather limited set of preconditions. I guess I'm happy as long as I can get way with just 'Xvesa'. Obviously I'm not intending to try some gaming. I agree as soon as you start doing that you'll end up needing accelerated graphics.
I'm currently without a system on which I could continue a bit more of my experiments. From memory I'm pretty sure that I had 'Mplayer-xorg' running on 'Xvesa' without 'Xorg-7.5.tcz' installed (but with "libGL.so*" and "friends" copied into '/usr/local/lib'). I'm not sure to which degree the performance was degraded, but at least the short clip I played did not seem to mind.
Likewise I had a play with 'gnome-desktop-base.tcz' without 'Xorg'. Mind you that was before the rebuild, so that trial was based on 'Xorg-7.4'. IIRC there was just one file which needed "libGL.so*" ('gnome-screensaver-gl-helper' if my notes are correct). I had just a fairly cursory glance over things, so again I don't know what else might be missing without 'Xorg-7.4' installed and it's X-server running.
I remain to be still curious to which degree the "full Xorg" is required in some cases and might pick up this subject again when time and system availability allows.
-
I'm currently without a system on which I could continue a bit more of my experiments. From memory I'm pretty sure that I had 'Mplayer-xorg' running on 'Xvesa' without 'Xorg-7.5.tcz' installed (but with "libGL.so*" and "friends" copied into '/usr/local/lib'). I'm not sure to which degree the performance was degraded, but at least the short clip I played did not seem to mind.
That's true, Mplayer-xorg does run if the lib is available, but only with the same outputs as Mplayer-nodeps (likely picking the x11 output by default). If you try "-vo gl" to force the GL output, it's a no go with Xvesa.
-
gnome desktop with Xvesa is not a good option because of bad performance and there are certain things that requires Xorg server, gnome keyboard layout switch, gnome screensavers, gnome display properties etc.
-
I get
render error detected, EIR: 0x00000010
page table error
PGTBL_ER:0x00000001
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detected, EIR: 0x00000010
page table error
PGTBL_ER:0x00000001
But mu power button still works, I can press it and it will shut down, I don't hve to hold it in for 5s. Ctrl-alt-bksp or ctroil-alt-del don't work, so I don't know if the power button activates some bios command, or my acpid files.
This bug has been found and fixed in other distros. Apperently it is not distro-related; it is a pre-i965 issue. See
http://bugs.freedesktop.org/show_bug.cgi?id=22936 (see comment #13)
http://bugs.freedesktop.org/attachment.cgi?id=33194
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/404064
-
No, I doubt it's that; that commit was merged to the kernel in 2.6.33-rc8...
-
I did some more googling with "[drm:i915_handle_error] suspend resume" and the boards are fairly buzzing with this bug. Very recent activity.
https://bugzilla.kernel.org/show_bug.cgi?id=15659 (see especially comment #53)
http://forums.gentoo.org/viewtopic-t-821387-postdays-0-postorder-asc-highlight-gpu+hung-start-25.html
And many many others.
It seems centered around kernel 2.6.32 - 2.6.34 and the i915 drivers.
-
There are only 31 comments on that bug?
-
There are only 31 comments on that bug?
Apologies - with all the pages I scanned I managed to stuff up. :P This is the one:
https://bugzilla.redhat.com/show_bug.cgi?id=573177
-
I have found a way to save anything needed to debug this. Ask and ye shall receive.
Attched is my machine's dmesg. The GPU fun is right near the bottom.
-
Well. This is not Xorg-7.5 related - I just tested suspend-resume with Xvesa and although dmesg looks different, it also seems to crash the GPU. I don't know how I got a different result last time - with the transition to 3.x, I must have gotten confused about which kernel was involved.
So the bottom line is, suspend-resume no longer works with 2.6.33.3-tinycore. This stuff could be moved to its own kernel bug thread, I suppose?
-
suspend/resume works for me in tc-3.x with Xvesa, but not Xorg-7.5
In tc-2.x suspend/resume works with both Xvesa and Xorg-7.4
..all on the same machine.
-
Did /usr/local/lib/X11/modules/extensions/librecord.so compile with Xorg-7.5?
-
I don't think I changed anything wrt record, so since it's not there, I assume it defaults to off.
edit: confirmed,
--enable-record Build Record extension (default: disabled)
-
I've found the bug. When you remove waitforX from your .xsession, everything, including suspend works fine
-
But not only intel produces bugs here with the new KMS.
When starting Xorg for the first time you will only get a KMS vt, but no fully functional X session. So, you either have to kill and restart Xorg, or "modprobe radeon modeset=1" manually at the top of .xinitrc.
-
Why not put the modprobe in bootlocal.sh ?
-
I'm not sure. From where and when exactly does startx get called at startup?
-
end of ~/.profile ?
-
I'm not sure. From where and when exactly does startx get called at startup?
As the very last step of the '~/.profile' of user 'tc'. This profile gets copied from '/etc/skel/.profile' and there are a few conditions to be fulfilled:
(1) that a file '/etc/sysconfig/Xserver' exists, which I believe means that a X server is defined (which defaults to 'Xvesa'),
(2) that no file '/etc/sysconfig/text' exists, which I believe means that the 'text' boot code was not used, and
(3) that no socket '/tmp/.X11-unix/X0' exists, which I believe means that no X server ':0.0' is already running.
-
As the very last step of the '~/.profile' of user 'tc'. This profile gets copied from '/etc/skel/.profile'
Note: Gets overwritten if contained in backup.
-
Oh right, I guess I should go to bed.
-
Some status rambling for those interested.
I'm aware 7.6 is out. However, 7.6 has started to depend on xcb, which would force bloat both on the base and the Xorg extension.
Resistance is not futile just yet though. I may be able to build 7.6 with the xcb-needing components being the last version that didn't need it; and if that's not the case, the next update will be 7.5-2, being somewhere between 7.5 and 7.6, like 7.4-2 was between 7.4 and 7.5.
It saddens me that by 7.7, about a year forward I guess, it will be much more difficult to avoid that. What we'll do then I have no idea yet; maybe we'll assimilate, maybe stay on older Xorg.
Finally, none of this is happening very soon, there's no urgent need for a Xorg update, so it will come when it's ready.
-
Yeah, Xorg is depressing. For me, with 7.4-2 multi-monitor stopped working properly, so I went on living with 7.5 and all it's bloat.
But are there any other ways to get multi-monitor support and some kind of video acceleration for mplayer apart from Xorg?
e.g. most of these embedded multimedia gadgets use the framebuffer directly I think.
-
No, unless you happen to have one of the older Matrox cards.
The normal framebuffer has no support (clone mode happens automatically IIRC, but I think you mean proper multi-screen). The matrox fb has card-specific dual head support.
KMS framebuffer can in theory do multiple screens, but no code exists so far, and the devs' opinion is that this feature is very low priority.
-
Some status rambling for those interested.
I'm aware 7.6 is out. However, 7.6 has started to depend on xcb, which would force bloat both on the base and the Xorg extension.
How does this statement stand in the light of this statement:
Small platforms: Xlib is a large piece of code, and it is difficult to make it smaller.
( from the xcb website, given as one of the reasons for going to xcb instead of Xlibs?
-
I don't know anything about Xorg and friends, but from what I read xcb aims to be backward compatible and uses lots of XML files. Form your own opinion...
-
How does this statement stand in the light of this statement:
Small platforms: Xlib is a large piece of code, and it is difficult to make it smaller.
( from the xcb website, given as one of the reasons for going to xcb instead of Xlibs?
XCB is an additional ~23 libs not needed before. It doesn't decrease total size in any way, it's an increase.
-
No, unless you happen to have one of the older Matrox cards.
The normal framebuffer has no support (clone mode happens automatically IIRC, but I think you mean proper multi-screen). The matrox fb has card-specific dual head support.
KMS framebuffer can in theory do multiple screens, but no code exists so far, and the devs' opinion is that this feature is very low priority.
So how do all these linux embedded devices solve the problem?
I just heard about opengl es...?
-
I unfortunately need Xorg 7.6. I know it's bloated.
Are there any plans to "officially" support it. I'm pretty far along in building myself; would be happy to share what I've done.
-- Bruce
-
It's on my todo list, but not in the near future (as in this week or the next). Will happen this summer though.
I'm a bit on the fence whether 4.x needs to happen first; with all the KMS dependency, 7.6 may not be too happy with our current kernel. Intel in particular is not happy about not running in lockstep.
-
It's on my todo list, but not in the near future (as in this week or the next). Will happen this summer though.
I'm a bit on the fence whether 4.x needs to happen first;
Curaga,
is there a draft schedule for 4.0 and Kernel version selection?
-
As mentioned in the wishlist thread, it will be kernel 3.0 if nothing comes up. TC 4.0 has no schedule yet.