Tiny Core Linux
General TC => General TC Talk => Topic started by: Yleisajattelija on January 19, 2012, 06:36:38 AM
-
I have used TC few months now. We have tried few TC installations to workstations and laptotps. TC+Xvesa installation is solid, but basic problem is that vesa standard is not updated anymore, so new motherboard (Intel DZ68DB) current BIOS is missing resolutions for 9/16 -LCD-displays.
So, Xorg have to be installed, but that rarely works at this moment on TC installation. Probably this is not TC -problem, I think that Xorg+X-stack is not working, as usual.
What is a solution? Xorg supplies source codes only. Xorg-source compiling is distro staff work, I think.
Didn't found TC Xorg/X-stack display drivers installation/config docs, is there any?
-
I have two machines with intel graphics hardware - which is notoriously buggy - and for the first time, with Xorg-7.6, both of them work "confless".
Did you try the above scenario (xf86-video-intel needs to be loaded)?
-
One problem is that we eventually got one old Intel 815/915-whatever-oldtimer-chip installation working by SEPARATELLY loading that xf86-video.intel driver before Xorg (I'm not sure if this was true reason for this "unexpected win", maybe we accidentally changed newer TC version at same time)
I think think is NOT Xorg meant to be, they presume loading automatically ALL drivers, needed or not. I personally prefer semi-automatic installation, which you can select installed driver manually.
Anyway, TC Xorg installation docs are not valid at this moment. I'm not The best person to document TC X-stack. Someone knows better, documentation (desperately) needed.
-
One problem is that we eventually got one old Intel 815/915-whatever-oldtimer-chip installation ...
You can use Xvesa + 915resolution with this hardware to get the required resolution
-
If the chip is i8xx, Intel has dropped support a while ago. On those chips vesa may even work better than the intel driver.
-
Yes, but now I have to insatall Intel Sandbridge 2-gen Core i3 + GPU-2000. Driver is published 11/2011, and (suprisingly!) latest TC is probably supporting that chip.
Question: Do I have to load xf86-video.intel before Xorg? And that graphics-whatever-it-was package? That 2000 GPU is included MPEG-decoder, I want that to work, too.
-
No need to manually load intel or graphics. They are deps (or subdeps) of Xorg-7.6.
For the Sandy Bridge video accel, I think our libva extension is too old (and you'd need a player that supports va-api, I'm not sure if we have one in the repo).
-
I have a machine with intel hd3000 graphics and Xorg-7.6 works confless with it.
-
I just loaded latest TC, I will try installation tonight.
FLTK seems very efficient, OpenGL support should be, too. Minimizing X-stack sounds VERY good idea, I don't know if it is possible in this case. I think serious programmers typically wants simple API:s, so it is possible to build mimimalistic X-stack.
I did look that Intel HD2000/3000 instruction set, and that 3D-api is VERY complicated. Of course, those rendering staff etc. need specialiced HW, but THAT is too much. That uP-GPU-MPEG-decoder integration idea may be good, it should remove lot of slow bus traffic.
But, as allways, at real life speed depends on driver and X-stack efficiency.
-
TC 4.21 installed. Locales setup and Xorg driver for Intel core 3i HD2000 won't work out of the box. Problem is how to fix it. At least Xorg installer should be interactive (I know, that is not possible).
Xorg is probably using standard udev handshake, so this is kernel problem. That is anyway key point for systematic installation. "Major bug fix" would be to modify udev kernel handshake -process to create PCI/USB-device list first and then prompt user recursively for drivers found by udev.
By the way, TC installation user interface is excellent, simple and handy. Pro, I would say.
-
Seems that Xorg is heavy user of udev. Probably USB stics etc removable media need udevd (mdev is some kind of static brother of udev).
udev is "child of Unix", use to be small at first, gigantic piece of code nowdays.
These constant installation problems with Xorg are probalby related to that Xorg special udev use. Should be static process at boot, dynamics should be for USB etc. only.
Should be like this:
a) TC BusyBox/Xvesa system on USB-stick. Lets name it as "Pelasti". It is not just rescue stick, but installation and maintenace stick too. TC main numbers (5.xx, 6.xx ...) needs new Pelasti, same main mumber (X.01, X02, ...) just update drivers
b) Target installation with Xorg (maybe with Gnu utils) on HD or/and flashdisk with drivers installed. Removable media (USB), needs set of drivers. This is not problem, because USB-driver is two-layer, only need upper layer drivers.
c) Target drivers installation have to be done two times (second time just Xorg-drivers)
d) If TC installation prosedure could support this interactive udev "device driver loading at installation", EVERYTHING would be easy
e) Becouse TC is not supporting this genius interactive process, I have to do it manually: lspci, lshw, udevadm, read_EDID etc. set of tools must be loaded on Pelasti. With some digging /dev /sys directories may be enough to save world
This not necessary solve these problems with Xor-drivers, but lets try...
-
Seems that this 9/16 screen resolution problem is very common on current xvesa-bios on all distros.
Xorg -drivers for Sandbridge HD2000/HD3000 are not working at any distro, either.
That HUGE complexity on Intel GPU API is VERY costly now.
Juanito, is your HD3000 Xorg driver really working?
-
Juanito, is your HD3000 Xorg driver really working?
What do you mean by really working?
I'm using Xorg-7.6 and looking at the gui as we speak: [ 58.691] (II) intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2)
[ 58.691] (--) intel(0): Chipset: "Sandybridge Mobile (GT2)"
-
Obviously that HD3000 is working on Juanito's machine.
But, I mean:
Did it work "out of the box" TC installation, without rewriting whole Xorg code etc. tricks.
I did use latest TC and installed Xorg, and CRASH!
-
If I'd hacked things to make it work, I'd have said so.
It works right out of the box and without an xorg.conf
BTW, just to be clear, 3d doesn't work with any hardware requiring the intel driver at the moment...
-
HD3000 and HD2000 suppose to be very close relatives, but it is of course possibility that 3000 works and 2000 not.
I will oad again TC base system, set local keyboard and load only Xorg7.6 package. Deps should be OK, so lot of stuff should install with Xorg.
Probably it crashes again, I try get all logs to find out problem.
I will update motherboard BIOS, too.
-
Xorg for core 5i is installed succesfully.
But, only when graphics package is istalled first and then Xor package froma command line. Probably that graphics package pre-installation is not the key, but that command line installation is.
Anyway, it is MUCH better idea always load drivers from command line (typically runlevel 3), and that is real Unix way too.
Is that so in TinyCore?
Next HD2000, let's see what happens.
-
There are no runlevels in TC.
-
That was core-i5 arrendale, didn't find Sandy Bridge
Let's try this exellent quote system:
There are no runlevels in TC.
a) I did look foor TC init boot secuence documentation
b) I found one
c) I have read it now (several days)
d) I like this TC boot VERY MUCH
e) After carefully analyze, I found couple of extra words in that document
f) I cannot find explanation for tho extra words
g) So, I have to admit, there is good quality and simple boot in this Unix.
h) Yes, I have to admit, that documentation is plentiful, too.
i) I assume that those few extra words are gift for mankind.
Anyway, should I load those Xorg drivers from command or not?
-
Anyway, should I load those Xorg drivers from command or not?
I have Xorg-7.6 loaded "onboot" with the hd3000 and things work fine.
-
Sorry delay, HD2000 installation is now OK.
Just read TC Xorg installation docs, Xorg extension have to be loaded from command line.
Get rid of X with <ctrl><alt><backspace>, and then "tce-load -wi Xorg7.6.tcz", restart X with "startx", should load without crash.
-
BTW, just to be clear, 3d doesn't work with any hardware requiring the intel driver at the moment...
A bit late to pick this thread up again I know, but it just occurred to me to use the "script" command to get something on permanent storage before the crash using 3d acceleration with intel hardware and, on two different machines: $ script /mnt/sda4/tmp/test
$ glxinfo
[crash, reboot]
$ cat /mnt/sda4/tmp/test | grep -i "opengl\|direct\|server\|client"
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 7.10.3
OpenGL shading language version string: 1.20
..and: $ cat /mnt/sdb1/tmp/test | grep -i "opengl\|direct\|server\|client"
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 7.10.3
..so the 3d graphics is starting up and then crashing - kind of strange that this happens on old hardware - i945 - which worked with Xorg-7.5
-
TC "ideology" owns two spesific problems with Xorg:
a) TC is missing runlevels -> no proprietary state-machine for installation
b) Xvesa is needed before Xorg -> have to load and unload Xvesa driver modules before loading Xorg
Seems that Xvesa module-unload-cleaning process is not solid, and Xorg modules cannot load after Xvesa without total X-init. This is probably untested situation, because "normal distroes" does Xvesa load OR Xorg load, not both.
a) + b) means that there is no way to change Xvesa to Xorg without manual X shutdown.
That GPU-core on Sandbridge architechture is awful mess, I think only way is to wait until Intel get that 3D driver stabile.
That is very diffucult task to get Core-i family uP/GPU internal bus traffic to syncronize without lockups etc. on multicore environment.
Nowdays Intel is putting lot of effort to Linux-port, so I think that will eventually work flawless.
-
b) Xvesa is needed before Xorg -> have to load and unload Xvesa driver modules before loading Xorg
'Not totally sure I've understood your point, but I run an intel hd3000 machine with core64 and Xorg-7.6 without using/loading Xvesa (which will not work with core64 anyway)
That GPU-core on Sandbridge architechture is awful mess, I think only way is to wait until Intel get that 3D driver stabile.
I've tried several combinations of intel driver/mesa/libdrm all without 3d success - agreed.
That is very diffucult task to get Core-i family uP/GPU internal bus traffic to syncronize without lockups etc. on multicore environment.
Again not sure what is meant by this, but the machine above - quad core i7/hd3000 works for weeks at a time without problems...
-
a) + b) means that there is no way to change Xvesa to Xorg without manual X shutdown.
This situation is not special. The same happens when your distro is running the FOSS radeon driver and you install the AMD binary driver. You need a full reboot in that case, though, an X restart is not enough.
-
Again not sure what is meant by this, but the machine above - quad core i7/hd3000 works for weeks at a time without problems...
If driver works, it works. When one tries to get it to working is BIG difference if API is simple or not. I'm not 3-D accel expert, but seems that when developing faster 3-D chip it is "easy though" that complexity makes power. The eternal CISC/RISC -diskussion is here again.
I'm HW-dude -> simple is better.
'Not totally sure I've understood your point, but I run an intel hd3000 machine with core64 and Xorg-7.6 without using/loading Xvesa (which will not work with core64 anyway)
I think TC approach is to load linux from scratch. First load base system to get to cloud, then load applications you need. It's good way to start with Xvesa, because it works for sure. If you have not display at first, you cannot proceed. When you have xvesa, there is display, and you have possibiilty to fix Xorg problems.
P.S I don't understand with these ยค%# [quates], hex editor etc. badly needed!
-
It's good way to start with Xvesa, because it works for sure. If you have not display at first, you cannot proceed. When you have xvesa, there is display, and you have possibiilty to fix Xorg problems.
OK, but what I'm saying is don't start with Xvesa.
Boot with only core/core64 and no other extensions loaded, then load graphics-KERNEL, Xorg-7.6 (not Xorg-7.6-3d) and your choice of window manager and then "startx" and things should "just work"
-
Xvesa Xorg loading problem disappeared with TC4.5, congratulations!
Sorry, I cannot pinpoint any reason for that previous crash, I hope you already did localize it.