Tiny Core Linux
Tiny Core Base => Micro Core => Topic started by: tclfan on August 02, 2009, 01:57:42 PM
-
Experimenting with microcore and xorg-xvesa-lite.tce as well as xbdev, I am not getting gui desktop, just prompt, after displaying messages on creating .xauthority files and something like 'no screen found'... All works fine if I use the standard xvesa extension.
I am sure I am missing some configuration, due to my limited very knowledge in this area... What do I need to do in addition to placing these core elements in tce folder?
I sort of expected destop to come up with both xbdev and xorg-xvesa-lite, in the same manner it comes up when specifying default xvesa, without any additional work...
Please help me...
-
In the spirit of modular architecture built on microcore, target systems can be built from microcore and additional components. To start, in the microcore elements folder we have basic X infrastructure components, such as xlibs, xprogs and xserver (to chose from 3 options, xvesa being default).
My understanding was that taking microcore, the resulting system will be composed depending what choice of core elements will be placed in tce, which means that if I pick xprogs and xlibs (common infrastructure elements) and add xvesa plus jwm, then I should get in result our familiar and treasured Tiny Core... No additional configuration!
Now if I venture to chose another xserver from microcore elements, I am getting black screen and command prompt. Clearly there is more to a successful build on this architecture than just placing components in tce... Can anyone please point me to some info how to successfully integrate the other 2 xserver options? Please be considerate of the fact I am not necessarily familiar with xservers and was expecting (incorrectly) that the xserver elements listed in the core components are interchangeable without additional work...
-
All works fine if I use the standard xvesa extension.
Does this mean the "core elements" one, or the extension?
Which version of MC are you using? Can you verify if the core elements were loaded correctly? (i.e. run `startx` manually)
-
Just tested both. Work as advertised! Simple drop in replacements on my hardware. YMMV
And of course, with Xfbdev you must specify a framebuffer vga code.
I used vga=788 and Xfbdev booted without mods or editing.
With Xorg-vesa-lite is was as simple as dropping into my tce directory.
I would check that you have all the needed core elements mounted.
Check your .xsession is calling the expected Xserver and such is actually available.
Be sure you have updated your .profile and .xsession for the latest changes with v2.2
-
Thank you. This must be me then (or my hardware). I will re-do it tonight on several hardware, but at least your word inspires confidence that in principle it should work.
Just to make sure I am doing the right thing (this is to thatsarule's question):
1. On removeable media (USB stick or MMC card) I set up the tce folder
2. I copy to tce core elements (xlibs, xprogs and one of choice of xserver options, e.g. xorg-xvesa-lite) from core-elements library.
3. I copy to tce a windows manager - in this case jwm.tce
4. I boot from Microcore LiveCD specifying tce location (mmcblk0p1 in this case or sdb2. Therefore, e.g. boot option: microcore tce=mmcblk0p1
Now, thanks to modular architecture, this should result in booting to jwm without any additional configuration? Except that only with xfbdev the framebuffer vga parameter must be specified on boot code...
Please let me know if the above process is correct...
It did work for me when using default xvesa element, not other x core elements, so I hope it is not hardware picky...
Of course I mean microcore 2.2 gold in this case...
Once I manage to resolve screen resolution support issue (with one x or another, considering Xvesa does not support newer screens), this will open wide all the goodness of modularity, efficiency and system integrity of PPR/TCZ concept to build on...
Thanks very much for your help.
-
If you are booting from USB/MMC i.e., flash devices, then be sure to use the waitusb=5 boot option.
-
Yes, off course. In this case it is actually booting from LiveCD (For the moment), just tce is on USB or MMC, which would require waitusb time.
However, if it was actually booting from USB, then I am thinking waitusb should not be required, since it is already booting from usb, so usb must have been recognized by now? If this is correct presumption, this could eliminate waitusb=5 generated by usbinstall process and cut down on boot time? It is my wild speculation at this point since I did not have a chance to test it in practice yet...
-
Booting is one thing, mounting directories after boot is another. You will need the waitusb option.
-
I see. Thank you.
-
I did lots of testing with three laptops loading xorg-vesa-lite and xfbdev with microcore...
The results are mixed success and failure, which I can at this point attribute to these x core elements, not to the process of loading them by microcore:
1. xorg-vesa-lite refused to produce any graphical desktop on both new (1280x800) laptops, no matter what I did. However it did produce desktop on old Thinkpad T23, although in reduced resolution (800x600).
2. xfbdev did produce desktops on both new laptops, although in a familiar 1024x768 resolution, not better than default xvesa core element. However it was able to produce desktop on Thinkpad T23 in it's correct resolution 1024x768. This was not working for me with Tiny Core default xvesa!
Now, although all the above is immaterial to microcore architecture topic, since this architecture works fine (Thank you RobertS!), I think (IMHO) that it would be of significant advantage if a robust support of displays (particularly newer ones) was found and made available as one of core elements, alongside with the three already there...
-
You always have the option of using the full Xorg extension.
However this would typically mean that you need an Xorg.conf file.
Therefore it would not be an automatic and is why it is not currently offered as a .core. type extension.
Note too that for many netbooks with intel video the inclusion of the 915resolution extension will often automatically setup their non-standard resolutions.
-
However this would typically mean that you need an Xorg.conf file.
Therefore it would not be an automatic and is why it is not currently offered as a .core. type extension.
Why not? For example SLAX by default creates xorg.conf during the startup. It is hidden for the user and works very reliable. Of course you can disable this behavior and keep saved conf if you want.
-
Reallly? When the xorg -configure does not work for my hardware, I typically then do not assume it would work for others without editing. It is one thing when things at least work on my test hardware. Are you saying Xorg configure would auto create the exact resolution that the user wishes?
-
My personal experience is that at least on machines I tried it was working. Also on the SLAX forum there are no discussions on this feature as I remember when I was active there. There is one trick, the generated xorg.conf is edited by a script. Do not remember details why, but can dig it out.
Anyhow it is easy. Try SLAX on your machine and see what happenes ;) This is always good to learn from others....
-
slightly OT: iirc, there is the (recent) xorg.confless feature of xorg, but it relies on hal
-
slightly OT: iirc, there is the (recent) xorg.confless feature of xorg, but it relies on hal
Sounds interesting, thanks. HAL is available now, however just to have Xorg configured it seems to be overkilling to use HAL and its dependencies, at least in TC terms :) But if you have all these ingredients already there because of a desktop environment for example, it would be whorth to try.
Is it available with the current Xorg package in the repo or it must be recompiled with this feature?
-
I think the ability to use Xorg without a config file has been around since about version 7.2, I was using it a couple of years ago. And I have used Xorg without a config file in TC when hal is not installed.
I have many machines, and I have had a hit or miss experience with live distros like slax that automatically configure full blown X. Slax offers a vesa mode of X to accomodate machines that will not autoconfigure.
Also, slax uses KDE which makes it easy to select the preferred X resolution. TC's typical window managers to not offer such convenience, which would require the user to manually edit xorg.conf anyway to achieve desired results.
-
Also, slax uses KDE which makes it easy to select the preferred X resolution. TC's typical window managers to not offer such convenience, which would require the user to manually edit xorg.conf anyway to achieve desired results.
For sure autoconfig is not a 100% solution but in most cases you can accept it without adjustment. If not, in worst case you can go back to the actual VESA mode, its easy. My view is that there are more pros that cons and it would increase user satisfaction. Or go for Xfce4, there is also a disply config tool :)
For example my desktop works fine with VESA, but the laptop display is so ugly that I have to use Xorg if want to survive using it regularly, not only for short testing.
VESA is safe and a must have, but for me only the second option.
-
From end user perspective I would add my two cents and support the opinion of Bmarkus. Correct resolution display is very important on LCD monitors. For testing or occasional use one could put up with ugly display on laptops but it is hard to suffer such for extended period.
E.g. Zenwalk, which is a well put together light LiveCD (Nothing is as light as TCL!), based on SLAX, appears to correctly and automatically configure display resolution using xorg. Furthermore, it appears to me that Austrumi, which is another small and light, run entirely in memory (Initramfs, like Slitaz and TCL) might be using xorg too, although I may be wrong on this one, inferring this conclusion only from resolution behavior...
None of the distros I know is architected as well (IMHO) as Tiny Core, but in the area of display support perhaps work done by others could be somehow leveraged to further improve user experience... If it is not too much to ask considering already fantastic achievement...
-
Apparently hal can be used for input related things... don't know whether or not it would require compiling though
@TCLFAN: did you try Xorg in TC?
-
How to use Xorg confless? It is clear, that a working HAL system is required when Xorg starts. What else? Any practial advice welcome, especially a conf file example.
-
Apparently hal can be used for input related things... don't know whether or not it would require compiling though
@TCLFAN: did you try Xorg in TC?
Sorry, I did not have a chance yet, working long days with hardly any window for fun. I can only rely on others' positive reports...
Accidentally I just read that the new Austrumi (1.9.4) has also full support for ATI, Intel and nVidia chips, which is surprising for Initramfs run-all-from-memory little Linux. I did not have the time to test how good it is either, but one thing I know by now: Nothing matches Tiny Core's architecture and network support (not even SliTaz), so Tiny Core is a new star and deserves special care. Therefore I see video as the next frontier here, in order not to limit this gem to special purpose systems...
-
Made some experiments, result is interesting.
Actually I am using Xorg.
- Exited to command
- Deleted all files in /etc/X11 now it is empty.
- Stopped HAL
- Entered 'startx'
No error message, display is the same as before. Everything looks fine, and still /etc/X11 is empty
Hm.... .
Strange. maybe some caching? Repeating it with HAL running result is the same.
EDIT: Not strange, this is the confless feature. No cache, just autodiscovery!
-
Xorg is using a hardware discovery based on different sources, HAL is just one of them. It is true, that 'Xorg -configure' works fine to create xorg.conf without HAL.
Now the question is, if Xorg can create the config file, why do you need the config file to use Xorg?
Answer is simple, you do not need it! This is the confless Xorg setup ;)
xorg.conf is used only to override result of the discovery, as it has the largest priority, so you can correct false detection or add extra features. It makes the Xorg setup much more easier than described in the WIKI in fact :-*, modification of .xsession must be enough, expecting prerequsits installed.
Another benefit of confless is that it works at startup, so using the same USB stick on a different machine will adapt Xorg to the present hardware.
^thehatsrule^: thanks a lot for mentioning confless, I didn't know this feature.
-
The wiki? Did you mean the .info?
In any case, I think the steps were described like this to cover the most general cases... I recall some confless problems with some framebuffer things a while ago (perhaps not a problem now).
-
The wiki? Did you mean the .info?
You are right, .info But this topic deserves a good WIKI article too. I was thinking on this typing the answer.
-
In any case, I think the steps were described like this to cover the most general cases... I recall some confless problems with some framebuffer things a while ago (perhaps not a problem now).
There are and will be always issues with automatic configuration. But my advice to give it a chance and if doesn't work, use VESA. For sure more than 50% will work just as it is without fine tuning. In this case using autoconfig in TC when Xorg is install would be a benefit for all.
-
I don't see graphics-2.6.29.1-tinycore.tczm listed as a dependency for Xorg-7.4.tcel, yet from the other thread it is sometimes required?
While these two extensions don't really qualify as .core. as they never existed in Tiny Core, I can easily make an automatic confless Xorg with the added dependency for v2.3rc1.
Still it wil be the same concept, drop in Xorg-7.4.tcel and with appropriate dependencies into your tce directory and the system witll boot into Xorg confless.
Still I have a concern about the dontzap of Xorg, if Xorg confless fails then the state of the machine is not easily recoverable.
-
I don't see graphics-2.6.29.1-tinycore.tczm listed as a dependency for Xorg-7.4.tcel, yet from the other thread it is sometimes required?
Hi,
following works on a stock TC 2.2:
- install Xorg-7.4 & graphics-2.6.29.1-tinycore (of course with their dependencies in .dep)
- make a backup of .xsession in your home (e.g. 'cp .xsession .xsession.vesa')
- modify .xsession in ~ dir as described in .info of Xorg
- reboot with backup
TC will start with Xorg with autoconfig instead of VESA
Please note:
- /opt/.filetool.lst is not edited
- no any change done in /etc/X11
Drivers in graphics-2.6.29.1-tinycore are required, without them Xorg will not start, so do not miss it.
If Xorg doesn't start or it is unusable:
- reboot with 'tinycore text' option
- rename .xsession.vesa to .xsession in ~
- enter 'startx' command or reboot with backup
If you want to change some settings, place xorg.conf in /etc/X11 No need to have a full config file, enough to have only parts you want to override.
-
As from the .info:
.
This extension depends on graphics-2.6.29.1.tcem for
any kind of 3D or video accel.
.
Please note, for AGP or integrated AGP cards such as Intel
chips you will always need graphics-2.6.29.1.tcem.
So, it is sometimes needed. I'd guess autoconfigure wouldn't check for those files.
-
I tested the procedure with a notebook with Intel and on a desktop PC with integrated ATI graphics. Without graphics-2.6.29.1-tinycore Xorg do not starts, otherwise perfect.
COMMINITY:
Would you check the above described procedure on your machine with and without graphics-2.6.29.1-tinycore and report the result, including the description of you machine (brand, model & video hw)? It would help.
-
simple case: vesa doesn't require it. You could also check the filelist of the graphics extension to see what's in it.
-
There are two things that require a xorg.conf still:
- keyboard language, no way to detect this
- disabling DontZap
And there are the cases where autoconfiguring simply does not work, yet manual / downloaded xorg.conf works. And complex cases with multiple keyboards/mice/monitors/cards. And proprietary drivers from vendors like Ati and Nvidia.
Re HAL - yes it is not needed for autoconfiguring. It can be used for that, but as one can see from Ubuntu, it sucks for that (have a little rarer device, and no workie until you add a file that forces it to detect). It does have a good side, input + screen hotplug (without one needs to restart Xorg).
HAL support is not compiled in, from two reasons:
- longer startup, bigger size, unneeded errors when checking for HAL and it isn't there
- HAL was not available as an extension when Xorg was made
-
HAL:
I don't think that HAL support in Xorg would give real benefits even if HAL is available, so it is safe to omit, also to keep TC tiny and not to increase size if not really necessary.
KEYBOARD LAYOUT:
You are right. However keyboard layout is already available in /etx/sysconfig so it is possible to create xorg.conf with keyboard def or to modify this part if already exists.
-
While these two extensions don't really qualify as .core. as they never existed in Tiny Core, I can easily make an automatic confless Xorg with the added dependency for v2.3rc1.
Still it wil be the same concept, drop in Xorg-7.4.tcel and with appropriate dependencies into your tce directory and the system witll boot into Xorg confless.
Thank you Robert S.! Now it instills hope this significant development progress (Thank you Bela Markus and all development team!) will not die and will surfice in TCL 2.3, especially it has been very quiet on this topic for some time, which I interpret as good sign... I am anxiously looking forward to this...
In the meantime, I had an opportunity to end-user test behaviour of the confless Xorg in Austrumi 1.9.4 (another in-memory very light distro, where Xorg is default) on 5 machines and it appears to work very nicely...
Only on very old laptops (Thinkpad 600 and T23) it produced desktop with too optimistic resolution, which was easy to correct on the desktop menu. On newer computers (one desktop and two widescreen laptops it produced beautiful desktops with the correct resolutions (Laptops 1280x800 and desktop 1920x1280 I think). Now I am not sure if all this can be attributed to confless Xorg alone or to the nVidia and ATI drivers, which are built-in by default in Austrumi.
I am pretty sure Austrumi does not use HAL. It is a small distro (91M ISO) packing lots of big applications in it, as Firefox 3.6a, Gnumeric, Skype, etc.
Zenwalk LiveCD, on the other hand, which is also using using confless Xorg renders perfectly correct resolution even on the two old laptops... Although it utilizes HAL since version 5, it behaved the same before HAL (up to version 4.8).
Seeing such good results and considering TCL has a fantastic project ownership and development team I can only look forward to the next release...
Just to mention, I have not seen any Linux evolving so rapidly as TCL! Although to be fair, I think Austrumi team is only two developers, so unfair to expect progress to be as rapid...