Using microcore with xorg-xvesa-lite and xbdev

[tclfan]

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...

[tclfan]

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...
 

[^thehatsrule^]

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)

[roberts]

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

[tclfan]

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.

[roberts]

If you are booting from USB/MMC i.e., flash devices, then be sure to use the waitusb=5 boot option.

[tclfan]

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...

[roberts]

Booting is one thing, mounting directories after boot is another. You will need the waitusb option.

[tclfan]

I see. Thank you.

[tclfan]

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...

[roberts]

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.

[bmarkus]

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.

[roberts]

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?

[bmarkus]

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....

[^thehatsrule^]

slightly OT: iirc, there is the (recent) xorg.confless feature of xorg, but it relies on hal