Page 2 of 2

Re: minimal Porteus question

Posted: 24 May 2015, 22:12
by quotaholic
yes: "video=lxfb:800x600-16@60" when added to kernel line of grubs menu.lst boots the hardware and if I am not mistaken that forces a kernel frame buffer. Made an xcb-all.xzm (from slackware 14.1 x/xcb-*) as well as a DirectFB.xzm. On boot now xorg.conf gets rejected and auto x script in Porteus fails and gives up. It keeps trying afterwards which makes reading Xorg.0.log hard but I saw that geode driver loads, then it tries for NSC module but EE it cant open it so it then loads vesa module. After vesa the last line reads that its loading fbdev and thats when flashing persists. The screen is cut to 640x480 output from the full 800x600 that vga=771 provided. Still though I cant test gui.

GPM seems to load allowing for some touchscreen action and event layer input. Not sure how to format xorg.conf for the framebuffer if thats the limitation here. /var/log/messages is not scrollable at this time and does not have any death messages at the bottom. Same with Xorg.0.log, only the fail on the opening of the NSC module.

Any tips?

Re: minimal Porteus question

Posted: 25 May 2015, 14:08
by quotaholic
Found the problem:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=637778

Now, how do I go about disabling the geode driver that is included in 002-xorg.xzm?

I can assign vesa in the xorg.conf but as long as geode is in the drivers folder x will try to load. Going in on init 3 and removing /usr/lib/xorg/drivers/geode_* resulted in a gui when startx was issued.

As I am impatient I will start to unpack 002-xorg.xzm and manually remove the drivers and repack. Will report back.

Thanks in advance

Re: minimal Porteus question

Posted: 25 May 2015, 16:36
by fanthom
not sure if that helps you but your may edit /etc/rc.d/rc.4 and disable Xorg watcher. this way Xorg will fail to startup instead of defaulting to VESA if native drivers are not found.

Re: minimal Porteus question

Posted: 25 May 2015, 17:28
by quotaholic
I got it. Repacking xorg.xzm without geode drivers helped. Had to delete /porteus/changes afterwards. I set up an init3 recovery in menu.lst on starting to build, just in case.

FYI anyone looking to build minimal: JWM does not take focus in a way that svkbd can work with. xvkbd with --always-on-top switch does not seem to work either.

Re: minimal Porteus question

Posted: 25 May 2015, 23:57
by quotaholic
Judging light weight desktops is best done on frail hardware. Looking at numbers on larger cpu based machines is figurative at best.

I looked over all the light weight desktop reviews before starting this project and lots talked about how much ram was occupied by various candidates. On a 400mhz cpu and 256mb of ram I have made some interesting notees.

LXDE took 25 minutes to boot to desktop and show the gui completely. 30 if you wanted to wait until the CPU came off full throttle.
JWM took 7 minutes 24 seconds but was later disqualified as it doesnt handle focus in a way that can be used with a touchscreen and on screen keyboard (all focus models tried in system.jwmrc)
E17 takes less than 6 minutes to start to show itself. 6:15 to see the desktop. The EFM file manager shows in 1.5 seconds after being called. XFE took 10 seconds on JWM.

Most probably dont care about this subject as most have quad core and ram to spare. Those of us interested in embedded may find this useful. E17 (without compositor enabled) was ahead by a factor of 2._ to one.

Re: minimal Porteus question

Posted: 17 Jun 2015, 18:29
by lm8
Would be interested to hear if anyone finds out anything further on this topic. Have you compared Equinox Desktop Environment to some of the other lightweight DEs? I hear LXDE is being replaced by LXQt which should be a little heavier, but still lightweight. Have you tried just OpenBOX which I believe LXDE uses? I use JWM a lot, but don't have the touch screen requirements. You can map a lot of the functionality in JWM to keys. Have not looked into onscreen keyboard support. dwm might also make a good lightweight window manager option, but not sure how it would perform with a touchscreen. I've seen a few distributions and some of the Linux From Scratch users running Wayland. Personally, I'm very interested in the DirectFB option. SDL 1.2.x and 2.x will work with DirectFB, so you can run any SDL programs with it. Haven't checked to see if a terminal multiplexer or a program like screen would work with DirectFB, but if it does, that could be really useful and possibly replace a window manager. DirectFB also has its own window manager, but I haven't tried it. I'm investigating whether some other GUI frameworks like FLTK will port to DirectFB. There's an older version of FLTK that works with it but nothing so far for FLTK 1.3.3. FLTK applications do work in framebuffer with nano-x though. I'm working on trying to find enough lightweight SDL and FLTK based applications to replace most standard desktop applications written with larger frameworks.

If you run across any more information on this topic, hope you'll share it. Thanks.

Re: minimal Porteus question

Posted: 17 Jun 2015, 19:53
by francois
Maybe this thread on openbox could be of interest for you:
viewtopic.php?t=2232&p=15393

I imagine that ncmprhnsbl will reply to any demand of information on that specific topic.

For the other aspects of your post, maybe you will have to wait for the passage of a developer: brokenman of fanthom.