xinput installed on puppy results in # xinput list commmand showing one mouse0 and keyboard0, the same command on L64 and all other linux distros results in a list of input devices as seen in hardinfo - input . a 'Master' is the head to which are attached the first keyboard and mouse and all other input devices. By creating a second master xinput allows you to attach to it a second keyboard and mouse which gives another pointer that acts indepedently of the first as in multi-touch. You can of course create several masters with several pointers and keyboards etc. It may be possible still to 'map' a master to a display/screen/desktop. Which is useful for me and my family to share one pc with extra displays keyboard and mice = pseudo multi-seat without nested servers = accelerated graphics and much better performance. Not for most people's usage I know.

xinput installed on puppy results in # xinput list commmand showing one mouse0 and keyboard0, the same command on L64 and all other linux distros results in a list of input devices as seen in hardinfo - input . a 'Master' is the head to which are attached the first keyboard and mouse and all other input devices. By creating a second master xinput allows you to attach to it a second keyboard and mouse which gives another pointer that acts indepedently of the first as in multi-touch. You can of course create several masters with several pointers and keyboards etc. It may be possible still to 'bind' a master to a display/screen/desktop. Which is useful for me and my family to share one pc with extra displays keyboard and mice = pseudo multi-seat without nested servers = accelerated graphics and much better performance. Not for most people's usage I know.

Ah, that's because xorg hotplugging is *NOT ENABLED* in puppy. The ones built with deb-build does work (if you also apply the pinstall.sh patches from rootfs). For others, what stemsee says is quite interesting, here's what Arch has to say about it: https://wiki.archlinux.org/index.php/Multi-pointer_X.
EDIT: typo.

@Mav, good that ZDRV is loaded into RAM
@Mick, (about -o64) I see, thanks. I use that "-o 64" because the default is "-o 0" (basically means that the start of the partition includes the partition table itself) and certain machines will not boot with this setup.

Quote:

--if suffix is -nfg then you absolutely know it's no good

LOL

Quote:

PS @jamesbond. re kernel-kit. Do you have a script for getting kernel firmware and cutting out inappropriate bloat?

No. What we usually do when we build the modules.sfs is something like this

Basically we copy whatever existing firmware in the running Fatdog, may be plus a few that others have reported missing in the forum. What we have in firmware is quite large and may contain obsolete stuff as well (I cleaned out radeon firmware before we released 630, I think, but there are many other that I haven't looked at) ..._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.Last edited by jamesbond on Mon 09 Jun 2014, 08:47; edited 1 time in total

Basically we copy whatever existing firmware in the running Fatdog, may be plus a few that others have reported missing in the forum. What we have in firmware is quite large and may contain obsolete stuff as well (I cleaned out radeon firmware before we released 630, I think, but there are many other that I haven't looked at) ...[/quote]

Exactly what I did and thought should be the solution.

XINPUT on puppy: After maybe two years I have my answer! Thank you Jamesbond. Barry Kauler owes you $50 au ! Or half anyway. lol

Also I am now typing from the trusty built in woof-ce-ng. Gave a blowfish result of 8.1 Unheard of!!!

I am posting from RSH's L.A.S.S.I.E running on latest 'stable' kernel 3.15 non-pae i486 (but says i686), just compiled on kernel-kit-ng by 01micko with initrd by jamesbond, and kernel-modues.sfs with lots of firmware, manually squashed by stemsee. Kernel is 4G highmem, 1g/3g split 1gb for kernel and 3gb for user/system. So 3gb appears in specs. timer =1000hz.
I forgot to remove suffix so uname -a gives 3.15-EmSee-pae but it is not pae! Sorry about that.

Just because it is quiet doesn't mean nothing is happening. Work on this is still on-going. Check out the "woof-next" branch of Woof-CE. It is still in early state - but it's moving. Summary here._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Sorry, can you please clarify your question? Also, if this is Fatdog-related question, that should go to Fatdog thread (use the one you see is still active)._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Not fatdog proper but the initrd in woof-ng. Does the initrd require a kernel argument to load a puppy.2/3/4sf file and where does it mount it? Is pupsave=ram:/path/to/savefile still valid? And can initrd parse a line DISTRO_PUPSAVE=puppy-save.2/3/4sf

Not fatdog proper but the initrd in woof-ng. Does the initrd require a kernel argument to load a puppy.2/3/4sf file and where does it mount it? pupsave=ram:/path/to/savefile still valid?

It is specified in DISTRO_SPECS that got included in initrd by build-iso.sh. You can't simply change them by specifying them from boot parameter (Mick, please correct me if I'm wrong). Fatdog's initrd (the real one, not the one in woof-next --- the one in woof-next's is still Puppy original initrd) does allow you to specify what basesfs you want to load through a boot parameter.

Anyway, basesfs, in Puppy's initrd, gets mounted in /initrd/pup_ro2. ZDRV (the kernel modules) gets mounted in /initrd/pup_z. Savefile gets mounted in /initrd/pup_rw, except when you use PUPMODE=13, where it will get mounted at /initrd/pup_ro1.

woof-next now builds the following (will boot up to graphical desktop with rox/jwm - at least in qemu):
- 32/64-bit ubuntu trusty
- 32/64-bit debian sid
- 32/64-bit slackware 14.1
It shouldn't be too difficult to do 32/64-bit debian jessie or 32/64-bit ubuntu utopic for anyone who wants to to do that.

All puppies have native package manager: debian/ubuntu have synaptics configured; slackware will have gslapt configured.

woof-next adapts Puppy to the parent distro; this is a different approach from current Woof2 which adapts the parent distro to Puppy.

The following infrastructure has been setup:
1. Build-time:
- rootfs-packages/debian-setup contains specific files/setup instructions for debian/ubuntu (currently they are shared, if later this is difficult, it can easily be split)
- rootfs-packages/slack-setup contains specific files/setup instructions for slackware.

2. Run-time:
There is an "rc.distro" which comes from the above "distro*-setup" rootfs-package, it is called by rc.sysinit to adapt whatever PATH etc so that puppy can run on top the base distro.

3. Size minimisation - the build infrastructure has commands to take out the most common source of bloats (doc, gtk-doc, etc).

4. Devx can be build in the same way like the basesfs is built (a sample devx pkglist is given for slackware)

The builders are more or less finished (unless if someone wants to contribute building from other parents, like Mageia, CentOS, etc - I think for me I'll stop at these three distros). The next (and long) journey is to test and adapt puppy scripts to work on top of these various parent distros._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

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