(old)Puppy Linux Discussion Forum

Posted: **Wed 06 Feb 2013, 18:51**

Its under uClibc-0.9.27...
asm/wm86.h do have a
#define IF_MASK 0x00000200
but no X86_EFLAGS

I was looking into using the "xcompmgr" with jwm to create some "cheep & cool" visuals...I will try again to get the composite introduced in the present code.
And after a second trial I think I will not want composite in here anyway - explodes in demand for xfixes, damage and undefined things.
And you are right - kdrive + composite is in Xorg1.2-1.4 - thanks!

Posted: **Wed 06 Feb 2013, 22:11**

goingnuts wrote:Its under uClibc-0.9.27...
asm/wm86.h do have a
#define IF_MASK 0x00000200
but no X86_EFLAGS

I was looking into using the "xcompmgr" with jwm to create some "cheep & cool" visuals...I will try again to get the composite introduced in the present code.
And after a second trial I think I will not want composite in here anyway - explodes in demand for xfixes, damage and undefined things.
And you are right - kdrive + composite is in Xorg1.2-1.4 - thanks!

If there's anything that should be included, it's xfixes. That's all the things that the core X protocol should have had, in one extension.

I ended up reverting the change in vm86.c and adding the snippet I posted in hw/kdrive/vesa/vm86.h

PS: all my changes are on github. So to clone the environment I'm using (you'll need a working git, gcc, binutils, and make):

Code: Select all

mkdir musl-toolchain
cd musl-toolchain
git clone git://github.com/idunham/musl
git clone git://github.com/idunham/tinyxlib
git clone git://github.com/idunham/tinyxserver
cd musl && git checkout g_hack && \
CFLAGS=-Os ./configure --prefix=/opt/musl && \
make && make install && cd ..
cd tinyxlib 
#vi standard_definitions.mk
make CC=/opt/musl/bin/musl-gcc && make install
cd ../tinyxserver
#vi standard_definitions.mk
make CC=/opt/musl/bin/musl-gcc
cp Xfbdev Xvesa ..
cd ..

Posted: **Thu 07 Feb 2013, 00:46**

I was looking at my C notes and see that vm86 is a syscall
http://linux.die.net/man/2/vm86

#include <syscall.h>
#include <sys/vm86.h>
int vm86(unsigned long fn, struct vm86plus_struct *v86){
return syscall(SYS_vm86,fn,v86);
}

(the older xvesa may need vm86old though?)

I've been seriously considering setting up my fast boot C implementation as a full time project if any pupngoers are interested, but only to mount the file systems, set some environment variables and start basic X... leaving the b.s. stuff that distro builders often change to be done inside X.

This will require several kernel parameters to be set such as:
mounts=/dev/sda1:ext3,/dev/sda2:ext4
swap=/mnt/sda1/pupngo/pupngo.swp #or /dev/sd[a-z][1-9]*
unions_ro=/mnt/sda1/pupngo/pup.sfs,/mnt/sda1/pupngo/devx.sfs
#unions will be layered in order they appear
union_rw=/mnt/sda1/pupngo/save.4fs
X=Xorg #can be Xvesa, xfbdev,... or something else entirely
Xscreen=640x480x16 #used by Xvesa -screen, todo accept "max"
LANG=en_US #any supported language
kb=us #any supported kb config
desktop=rox #none, jwm, pcmanfm, thunor, idesk, gnome, kde, ...
wm=jwm #icewm, mcwm, xdm, gdm, slim ... (window/display manager)
other parameters matching var=value will be set as env variables

This shouldn't be too difficult to accommodate in the installer, since the variables set in the gtkdialog wrapper can be used when writing the menu.cfg (or whatever gui/bootloader combo is chosen) ... the boot cd can have a set(s) of default parameters

possible future params:
user=root #spot, ... user defined?
toram=all # all=load all sfs in ram, 1 (only first sfs) 2, 3,... ?
module_dir=/lib/modules/3.8
modules=subdir_path/somemodule.ko,.../another.ko
#note, modules needed for boot should be builtin if possible ... the 3.8 kernel makes it much easier to load modules using only the filename without needing to memmap the file first (finit_module could be backported)

Normal init processes have the ability to halt, shutdown and reboot. I was thinking this could be set up by reading a file or fifo in a loop at the end of the init that could be written to by simply echoing to /tmp/.init ... thus the traditional command to shutdown/restart: init 6 ... could be emulated by echo $1 > /tmp/.init

I am trying to keep everything as libc independent as possible, to the point of writing my own implementations of many standard functions like fprintf, printf, strlen, strcmp, strncmp (todo: fork and exec* via syscalls)

Posted: **Thu 07 Feb 2013, 00:56**

Well, debug time for me.
I have X starting, fonts and mouse working...but NOT keyboard.
Instead, xev tells me the right keycode but "keysym NoSymbol, 0x0".

EDIT:
It seems you can use xmodmap, so I went:

Code: Select all

#in full X server:
xmodmap -pke >.Xmodmap
#exit X
#delete last few lines of .Xmodmap - old X thinks keycode 248 is too high
Xfbdev &
#Ctrl Alt F1
DISPLAY=:0 icewm &
#Ctrl Alt F1
#apparently you need to load AFTER the wm, for unknown reasons?
DISPLAY=:0 xmodmap .Xmodmap

Posted: **Thu 07 Feb 2013, 15:53**

technosaurus wrote:I've been seriously considering setting up my fast boot C implementation as a full time project if any pupngoers are interested

If this means a new cutdown os could I make a request? I'd like to see a basic boot environment that is fully "Top Left Justified" in the sense that x=0, y=0 identifies the top left of the screen. (Like the hardware sees it...)

As soon as things like a "menu" button, or drive icons become referenced to the lower corners it seems to makes it harder to run on systems that have low res monitors. If everything is referenced to top left then it should be easier to make an os that "grows" outwards from that point and is not so easily upset by the "foldback" that occurs when programs like rox try to position desktop items relative to a "floating" bottom edge of screen.

(Probably I'm explaining this badly but oh well...)

Posted: **Thu 07 Feb 2013, 17:35**

@technosaurus: I'm in - I might only be able to contribute with testing your stuff.
@Ibidim: I do not have git - tried to compile it from source but failed. Then tried a pet found here but I miss some libs. Then got the sources as zip-files but couldn't find the g_hack. Anyway installed musl, tinyxlib & tinyxserver. While compiling tinyxserver got stuck in
/hw/kdrive/linux/agp.c - missing headers in asm and linux - supplied that from main system but got conflicting types for 'fd_set/dev_t/ino_t/mode_t/nlink_t/off_t/suseconds_t/timer_t/uid_t/gid_t...

I really would like to use musl but I seem to get stuck with something when I try...Any hints to get further?

Posted: **Thu 07 Feb 2013, 17:52**

when I was building musl it helped to edit the musl-gcc wrapper to add defines for xopen, bsd and gnu source.

Posted: **Thu 07 Feb 2013, 18:50**

greengeek wrote:
technosaurus wrote:I've been seriously considering setting up my fast boot C implementation as a full time project if any pupngoers are interested
If this means a new cutdown os could I make a request? I'd like to see a basic boot environment that is fully "Top Left Justified" in the sense that x=0, y=0 identifies the top left of the screen. (Like the hardware sees it...)

Yeah, if I am making it slow enough to need boot messages, I consider that a bug... in other words rather than being top left justified. I think messages should be unjustified. (pardon the play on words) Ill leave it to the distro builders and users to handle the desktop layout as it is a simple task and everyone has his own opinion of what is best.

Posted: **Thu 07 Feb 2013, 20:06**

goingnuts wrote:@technosaurus: I'm in - I might only be able to contribute with testing your stuff.
@Ibidim: I do not have git - tried to compile it from source but failed. Then tried a pet found here but I miss some libs. Then got the sources as zip-files but couldn't find the g_hack. Anyway installed musl, tinyxlib & tinyxserver. While compiling tinyxserver got stuck in
/hw/kdrive/linux/agp.c - missing headers in asm and linux - supplied that from main system but got conflicting types for 'fd_set/dev_t/ino_t/mode_t/nlink_t/off_t/suseconds_t/timer_t/uid_t/gid_t...

I really would like to use musl but I seem to get stuck with something when I try...Any hints to get further?

Did you download this?
http://github.com/idunham/musl/archive/g_hack.zip

Conflicting types?
I haven't seen that, except when I passed -I/usr/include; but it could be a branch-specific difference...try again with what I just mentioned, and run something like this:

Code: Select all

cd /opt/musl/include
for d in linux asm asm-generic mtd sound video rdma; do ln -s /usr/include/$d .; done

I've made sure to add -D_GNU_SOURCE -D_XOPEN_SOURCE=700 to the CFLAGS in standard_definitions.mk
Also, what kernel-headers are you using?
I'm on 3.4.

Posted: **Thu 07 Feb 2013, 21:06**

ok got it. Did the above things and got same errors. If added -D__KERNEL_STRICT_NAMES to xserver standard_definitions.mk it builds - missed libz but after that it links. I haven't tested yet if it runs - must postpone that till tomorrow. My kernel is 2.6.25.16. The -D__KERNEL_STRICT_NAMES bypasses all the conflicting stuff in /linux/types.h...

Posted: **Thu 07 Feb 2013, 22:54**

OK, good to know about that little bit. I guess the kernel headers got stricter later in the 2.6 series.
Do you know whether adding -D__KERNEL_STRICT_NAMES works with your version of uclibc?

(I'm considering adding that to the default CFLAGS.)

also, about git:
Minimum "full-featured" build requires gettext/libintl (recommended; it's a real pain to workaround, but is possible), libcurl (http fetch), and probably perl as well. You may also want OpenSSL for pulling over https, in which case curl must be linked with openssl also; expat is only for http(s) push.
You need to edit the Makefile for git or set variables in the make command.
eg, bare minimum/no curl but gettext, libintl, and perl (with libintl-perl module) are installed:

Code: Select all

make NO_PYTHON=1 NO_EXPAT=1 NO_CURL=1 NO_OPENSSL=1

This can only fetch or push over git:// or git@github.com
If you have expat, openssl, and an openssl-libcurl, you can drop the appropriate NO_ options.

Posted: **Fri 08 Feb 2013, 06:34**

Xvesa musl build works. Seems -D__KERNEL_STRICT_NAMES works with uclibc too. I will try a new git-build this afternoon.
Update: Got the git to build static - would have liked to post it but forum seems to allow max 256K attachments atm.
20130209: attached minor patch (diet libc build/removed some warnings/some errors in respecting standard_definitions.mk in makefiles)

Posted: **Mon 11 Feb 2013, 01:54**

goingnuts wrote:Xvesa musl build works. Seems -D__KERNEL_STRICT_NAMES works with uclibc too. I will try a new git-build this afternoon.
Update: Got the git to build static - would have liked to post it but forum seems to allow max 256K attachments atm.
20130209: attached minor patch (diet libc build/removed some warnings/some errors in respecting standard_definitions.mk in makefiles)

OK, but I'm curious about one thing: what did -DXKB_IN_SERVER do?
Ah, nothing by itself, just an internal macro that flagged whether to use the server or the client extensions. I probably should switch the order in dix/devices.c...

XDMCP? I thought that was only relevant for thinclients and GUI logins. Not to mention that in the former case, it's insecure.
I could be wrong, though.
Usually SHM is needed, and I think Xrender is something Firefox needs.

I'm changing the standard_definitions.mk so as to allow setting RGB and FONTPATH to the paths, rather than changing embedded definitions. This should allow switching distros much more easily.

Posted: **Mon 11 Feb 2013, 03:05**

Ibidem wrote:and I think Xrender is something Firefox needs.

Xrender also seemed to be a requirement for Freeoffice 2012 when I tried adding it to pupngo2012.

Posted: **Fri 15 Feb 2013, 15:48**

Finally managed to build a Xvesa with the composite extension. Used below modified script where original is here:

Code: Select all

#!/bin/sh -e
CC_GLOBAL="gcc"
PREFIX="/opt/fd0"
INCDIR="/usr/include"
LIBDIR="/usr/lib"
export PKG_CONFIG_PATH="/opt/fd0/lib/pkgconfig:$PKG_CONFIG_PATH"
CFLAGS_GLOBAL="-pipe -Os -mtune=i386 -Wall -D_BSD_SOURCE -D__KERNEL_STRICT_NAMES "
LDFLAGS_GLOBAL="-Wl,--gc-sections,--sort-common,-s"
# THE LIBS
LIBS="Xproto Xdmcp XExtensions xtrans Xau X11 Xext Randr Render Xrender Xrandr FixesExt DamageExt Xfont ResourceExt RecordExt CompositeExt xkbfile Xfixes Xcomposite Xdamage"

for LIB in $LIBS; do
	cvs -d :pserver:anoncvs@freedesktop.org:/cvs/xlibs co "${LIB}"
	pushd "${LIB}"
	./autogen.sh --prefix="${PREFIX}"
	make CC="${CC_GLOBAL}" CFLAGS="${CFLAGS_GLOBAL}"
	make install
	popd
done
# THE SERVER --with-fontpath="/usr/X11R7/lib/X11/fonts/misc/"
cvs -d :pserver:anoncvs@freedesktop.org:/cvs/xserver co xserver
pushd xserver
./autogen.sh --prefix="${PREFIX}" --enable-composite --disable-ipv6 
make CC="${CC_GLOBAL}" CFLAGS="${CFLAGS_GLOBAL}" LDFLAGS="${LDFLAGS_GLOBAL}"
install -d "${PREFIX}"/bin
make install
popd
# Above wont build a static server...so example of doing Xvesa static below:
pushd xserver/hw/kdrive/vesa

${CC_GLOBAL} ${CFLAGS_GLOBAL} -static ${LDFLAGS_GLOBAL} -o Xvesa vesainit.o  libvesa.a ../../../dix/libdix.a ../../../os/libos.a ../../../hw/kdrive/src/libkdrive.a ../../../fb/libfb.a ../../../mi/libmi.a ../../../Xext/libXext.a ../../../record/librecord.a ../../../render/librender.a ../../../randr/librandr.a ../../../xfixes/libxfixes.a ../../../damageext/libdamageext.a ../../../composite/libcomposite.a ../../../miext/damage/libdamage.a ../../../miext/shadow/libshadow.a ../../../dix/libxpstubs.a ../../../hw/kdrive/linux/liblinux.a "${PREFIX}"/lib/libXfont.a "${PREFIX}"/lib/libfontcache.a "${PREFIX}"/lib/libXau.a "${PREFIX}"/lib/libXdmcp.a -L"${LIBDIR}" -lz -lm

cp -af Xvesa "${PREFIX}"/bin

popd

Above can be modified to use dietlibc, uclibc or musl. I only had success using uclibc in a chrooted toolchain but that must be lack of patience from my side.

The fontpath is important for some applications to run (dillo, proview) - revise and change as needed or create the missing symlinks...

A static build of Xvesa and xcompmgr including a script to start the fun via /root/Startup/xcompmgr_start can be downloaded here Works fine in pupngo2012...
Add 20130215: To have transparent windows as well I tried to compile the pt. latest jwm (686). Had to upgrade the tinyXlib Xrender to do it, still jwm misses the code for avoiding sticky clients showing up in pager - and still the configure does not work if you have some of the needed libraries in static only form...
But anyway the new jwm seems faster. Attached a static build to play with - fake gz-file - just rename to jwm.

Posted: **Wed 20 Mar 2013, 08:23**

technosaurus wrote:I reduced the sizes of some of the danpei xpm icons a bit (enough to save ~20kb in the compiled binary size)
I may as well describe what I did to shrink them
open with mtpaint
Image -> convert to rgb
Image -> convert to indexed
check Min Max Quantize and Floyd Steinberg
change the number at the top to 92 (maybe 93?) or less
save as whatever (works for at least xpm and png, possibly others)
(use your best judgement based on the image - lower number of colors reduces size some, but may end up looking like trash if it gets too low - most small icon pixmaps look ok at 16 colors)
this works because reducing the number of colors below 93 causes the pixels to be represented by a single character ... effectively cutting the size in half (not including the reduction for each color ... ~16B ea. I think)
Note: I have had issues with some versions of mtpaint with this method especially if you do further manipulations of the pallette - it will sometime lose a clear background and need to be edited in a text editor.

Just want to get this on my list so I can refer back to it.

Posted: **Wed 03 Apr 2013, 15:12**

For console applications daily reviews and tests...continues the path of http://kmandla.wordpress.com/

Posted: **Thu 29 Aug 2013, 15:16**

Dragging up the original pupngo thread to continue blabla on more basic things...
Back in tinyXlib testing - got stuck with xdesktopwaves. It compiles ok but refuse to run as it cant translate color #406080 and other colors in same syntax. Adding "64 96 128 #406080" to rgb.txt helps a lot but seems to be an unusual hack.
So updated GetColor.c, Xcmsint.h, LookupCol.c, ParseCol.c. Added cmsCmap.c, Cmap.h, Cv.h, CCC.c, cmsColNm.c, XRGB.c, cmsInt.c, cmsGlobls.c, CvColW.c, LRGB.c, CvCols.c, cmsProp.c, HVCGcC.c, XYZ.c, uvY.c, xyY.c, Lab.c, Luv.c, HVC.c, cmsTrig.c, cmsMath.c, AddDIC.c, HVCMxC.c, HVCMxVC.c to X11lib which solves the problem.
BUT adds 20-30K to every binary linked against the new libX11. And most applications does not use the added functions at all. I do compile with "-Wl,--gc-sections,--sort-common,-s" but seems that the new functions are "glued" in...

SO: Are there any way to map the internal dependency of the functions in a library from source-code? If so this could be used to evaluate the consequences of adding functionality or to put in conditions when to use and when not to use...

The obvious solution to xdesktopwaves is to patch the source to use names from rgb.txt and bypass all above additions - but there might be applications that really benefit from the added functions...

Posted: **Thu 29 Aug 2013, 15:40**

goingnuts lives!

where you been man? I can't imagine I'm the only user (you're a dev, I'm a user

) who cares about pUPnGO...

Also, in the -2012 thread, bark_bark_bark has a question for you...

Posted: **Thu 29 Aug 2013, 18:26**

Been traveling back in time

trying to collect old goodies. Some seems to be out of reach already

(old)Puppy Linux Discussion Forum

pUPnGO - 6Mb ISO - Basic Building Block Puplet