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!

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):

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 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)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

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.

@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?

when I was building musl it helped to edit the musl-gcc wrapper to add defines for xopen, bsd and gnu source._________________Check out my github repositories. I may eventually get around to updating my blogspot.

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._________________Check out my github repositories. I may eventually get around to updating my blogspot.

@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:

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

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:

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.

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)

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.

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.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum