Puppy In-House Development

[Ibidem]

All UNIX-like systems are ILP32 or LP64 (if it purports to be POSIX, sizeof(int)==4 and sizeof(long)==sizeof(void*)).
But Windows is ILP64, where sizeof(int) == sizeof(long).
int32_t is ISO C, which is aimed at both Windows and *nix even though MS refuses to update their compiler past C89.

Toybox is aimed only at systems where sizeof(int)==4. It also expects POSIX2008 support.
The strncmp was done that way because I wanted to see why it wasn't playing.
A more toybox-ish way would be

Code: Select all

 if (strncmp(a, b, 4) || strncmp(c, d, 4) || strncmp(e, f, 4)){
  perror_msg("bad WAV header: %s", wav_file);
  return;
}

All the bswap_* stuff can be done via SWAP_BE*.
This could also be used for the comparisons if you don't want to do strncmp().

Code: Select all

   if (IS_LITTLE_ENDIAN) {
    //endianness-switching
  } else {
    //big-endian code
  }

is actually the "proper" style for toybox; modern compilers will turn if (1) {a;} into {a;}.

On the mixer, -l and -r would be nice; optstring would look about like this:
"l#<0>100r#<0>100"
This way the initialization code converts it to a long and checks the range.
Making list a separate command seems rather pointless; both need to open the mixer and call some ioctls on it.
Also, it's a standard part of most CLI mixers.

[Iguleder]

Edit2: @Iguleder, I noticed you also made an ogg player with stb_vorbis ... is there an advantage to using tinyalsa over /dev/dsp directly? ... aside from possibly missing a symlink from /dev/dspX like mixing multiple sources or support for platforms without OSS

Nothing but abstraction. Yes, I know it's not that complicated to kick tinyalsa, but it's ready, works well and small. Couldn't do it better myself.

[technosaurus]

What about a whole new paradigm?
Rather than having packages at all, just install all supported packages to the root of a web server and use something akin to httpfs as a replacement for the pup*.sfs (underlying read only filesystem)

Then only items that a user actually uses get downloaded (though a cache with rsync capability to the rw layer if available would be a nice addon)

With this I think we could get the distributed image down to ~1mb and not worry about updates, package management, and all that goes along with that.

@Iguleder, does LUUFS support the equivalent of whiteout files? --- something to allow the user to hide some .desktop files so the menu doesn't become unmanageable.

[Iguleder]

No, it doesn't. It doesn't allow the user to overwrite files from the read-only layer.

EDIT: @technosaurus, mouse wheel scrolling doesn't work in DSLR, with a 64-bit tinyxserver Xfbdev and GTK 1.x. Do you have any idea how to solve this problem? I know there was some magical X patch for this, but it's already merged into tinyxserver AFAIK. When I scroll xev it doesn't receive any events.

EDIT 2: I think evdev is the way go. I'm working on getting the vanilla X.Org 1.2 to build against tinyxlib, which lacks lots of required proto stuff.

EDIT 3: this is far too complex. Maybe adding evdev support to tinyxserver is the way to go.

[technosaurus]

see: http://cgit.openembedded.org/openembedd ... ver-kdrive

[Iguleder]

The KDrive input interface changed a lot, so this doesn't help much.

[goingnuts]

No, it doesn't. It doesn't allow the user to overwrite files from the read-only layer.

EDIT: @technosaurus, mouse wheel scrolling doesn't work in DSLR, with a 64-bit tinyxserver Xfbdev and GTK 1.x. Do you have any idea how to solve this problem? I know there was some magical X patch for this, but it's already merged into tinyxserver AFAIK. When I scroll xev it doesn't receive any events.

EDIT 2: I think evdev is the way go. I'm working on getting the vanilla X.Org 1.2 to build against tinyxlib, which lacks lots of required proto stuff.

EDIT 3: this is far too complex. Maybe adding evdev support to tinyxserver is the way to go.

Why not try the tinyXlib derived from XFree86-4.8.0? I found that this is much less complicated than using tinyxlib. Patches included in pUPnGO-2014-412 0.6Gb ISO

[Iguleder]

I couldn't get it to build with a modern GCC and musl, on x86_64. Remember, you use the ancient 4.12.

[goingnuts]

Actually using toolchain from here - guess with headers from even older kernel than P412 carries. Well - it was just a thought - you did manage to patch tinyxlib to build x86_64+musl.

[Iguleder]

It's the build system that's so problematic. It's a nightmare to cross-compile this thing.

Also, there are many tinyxlib incompatibilities in proto stuff. Since tinyxlib contains old xproto and other protocol headers, most X servers fail to build against it, so it's a chicken and egg problem. I can't get XFree86 or Xorg 6.9.0 to build, both the server and Xlib.

[technosaurus]

Sorry about that. I assumed it wouldn't patch cleanly but it looked to me that there were only a relatively few number of changes to be manually patched ... adding evdev.c and modifying some lines in kdrive/linux/* Should I use Isaacs's branch or Dima's to have a blind stab at it?

here is the player: haven't toyboxed the mixer yet (just trying to get enough to test sound in aboriginal builds, so will need the mixer to ensure volume is audible)

Code: Select all

/* wav.c - Plays wav file(s).
 *
 * Copyright 2014 Brad Conroy <bconroy@uis.edu>
 *
 * See https://ccrma.stanford.edu/courses/422/projects/WaveFormat/

USE_WAV(NEWTOY(wav, "<1", TOYFLAG_BIN))

config WAV
  bool "wav"
  default n
  help
   usage: wav [wav file...]

   Plays wav files.
*/

#define FOR_wav
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/soundcard.h>
#include "toys.h"

void do_wav(int fd, char *name){

  struct {
    char      ChunkID[4]; // "RIFF"
    uint32_t  ChunkSize;
    char      Format[4]; // "WAVE"
    char      Subchunk1ID[4]; // "fmt "
    uint32_t  Subchunk1Size;
    uint16_t  AudioFormat; //1
    uint16_t  NumChannels; //1==mono, 2==stereo
    uint32_t  SampleRate; //8000, 44100,...
    uint32_t  ByteRate;
    uint16_t  BlockAlign;
    uint16_t  BitsPerSample;
    char      Subchunk2ID[4]; //0x64617461 "data"
    uint32_t  Subchunk2Size;
  } *hdr = (void *) &toybuf; //to save 44 bytes

  read(fd,hdr,44);
  if (
    memcmp(hdr->ChunkID,"RIFF",4)     ||
    memcmp(hdr->Format,"WAVE",4)      ||
    memcmp(hdr->Subchunk1ID,"fmt ",4) ||
    memcmp(hdr->Subchunk2ID,"data",4) ||
    (1 != hdr->AudioFormat) //or mulaw, alaw, ima-adpcm?
  ) return;
#if !IS_LITTLE_ENDIAN
  bswap_32(hdr->SampleRate);
  bswap_16(hdr->NumChannels);
  bswap_16(hdr->BitsPerSample); 
#endif
  int value, dsp=open("/dev/dsp",O_WRONLY);
  if (dsp<0) return;
  value=hdr->NumChannels;
  xioctl(dsp, SNDCTL_DSP_CHANNELS, &value);
  value=hdr->SampleRate;
  xioctl(dsp, SNDCTL_DSP_SPEED, &value);
  value=hdr->BitsPerSample;
  xioctl(dsp, SNDCTL_DSP_SETFMT, &value);
  while ((value=readall(fd,toybuf,sizeof(toybuf))))
    writeall(dsp,toybuf,value);
  close(dsp);
}

void wav_main(void){
  loopfiles(toys.optargs, do_wav);
}

[Iguleder]

I think tinyxserver isn't worth the effort. It's too old and limited - evdev support is a minor problem compared to other deal breakers (e.g the lack of GTK+ 2.x support).

Ideally, I'd like to have working Xlib and Xfbdev/Xvesa in one sources tree, with makefiles, without redundant BSD/Windows/whatever code, support for cross-compilation and a -DTINY flag which disables big, unneeded features.

I really like Tiny Core's tinyx - they just stripped X.Org 1.2. However, you still need X.Org's protocol headers and libraries, so it kinda misses the point. It takes ages to build and maintaining so many small packages is a big burden.

[technosaurus]

I can try to revert the xvesa removal from mainline and have patches that remove bulky non-features... replace the static table based builtin iconv for at least the large asian locales with system iconv calls (or all of them? Leaving it up to iconv whether to use static tables ... just removing support for builtin large asian locales reduces x11 to ~850k and I already made a patch for that)

I also have a preliminary toybox mixer (improved) that I will post soon... feel free to scrape it for coding a tiny alsa version for dslr.

Edit:
Here is my working copy of mix.c - I had to make a sudden trip out of town for a funeral and forgot my linux flash drives (posting from win7 -yuk). It was pretty close to working IIRC, so give it a try if you wish.

Code: Select all

/* mix.c - A very basic mixer.
 *
 * Copyright 2014 Brad Conroy, dedicated to the Public Domain.
 *

USE_MIX(NEWTOY(mix, "m:d:l#r#", TOYFLAG_USR|TOYFLAG_BIN))
config MIX
  bool "mix"
  default n
  help
   usage: mix [-m mixer] [-d device] [-l level / left level] [-r right level]

   Lists/sets mixer devices/levels.
*/

#define FOR_mix
#include <linux/soundcard.h>
#include "toys.h"


GLOBALS(
   char *mixer;
   char *device;
   int level;
   int right;
)

void mix_main(void)
{

  const char *devices[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES;
  char *mixer_name=(toys.optflags & FLAG_m)?TT.mixer:"/dev/mixer";
  int i, mask, device=-1, level, mixer=xopen(mixer_name, O_RDWR|O_NONBLOCK);

  xioctl(mixer, SOUND_MIXER_READ_DEVMASK,&mask);

  if (!(toys.optflags & FLAG_d)){
    for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i)
      if (1<<i & mask) printf("%s\n",devices[i]);
    return;
  }else{
    for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i){
      if (!strcmp(devices[i], TT.device)){
        if (1<<i & mask) device=i;
        else return; //with error
        break;
      }
    }
  }

  if (-1==device)
    return; //with error

  if (!(toys.optflags & FLAG_l)){
    xioctl(mixer, MIXER_READ(device),&level);
    printf("%s:%s = %d\n",mixer_name,devices[device],level);
    //todo - handle left and right channels w/ bitops. if (level&0xff00)...
    return;
  }

  level=TT.level;
  if (!(toys.optflags & FLAG_r))
    level = TT.right | (level<<8);

  xioctl(mixer, MIXER_WRITE(device),&level);
  close(mixer);
}

[Iguleder]

Mouse scrolling works in tinyxserver!

I decided to see how DSL behaves - somehow, it doesn't recognize the Super keys, like tinyxserver, but mouse scrolling works. I couldn't find DSL's source code to see why. Its changelogs mention some patch that made mouse scrolling work, but I couldn't find any trace of it, in both DSL's stuff and X.Org's git.

I took a look at complaints of DSL users about mouse issues - in one of them, I saw a suggestion to run the X server with "-mouse /dev/psaux,5". I knew 5 means 5 buttons, after reading so much ugly X server code, so I grepped tinyxserver's code for mouse\". I found it in hw/kdrive/kdrive.c - there's a function that accepts this string and parses it. If you look closely enough, you'll see a variable which specifies the number of buttons - the default is 3.

I just changed the default to 5, since pretty much all mice have a scroll wheel these days. Now, when you run tinyxserver without any options, it uses the first mouse it finds and assumes it has a scroll wheel. Perfect

[Ibidem]

Edit:
Here is my working copy of mix.c - I had to make a sudden trip out of town for a funeral and forgot my linux flash drives (posting from win7 -yuk). It was pretty close to working IIRC, so give it a try if you wish.

Code: Select all

/* mix.c - A very basic mixer.
 *
 * Copyright 2014 Brad Conroy, dedicated to the Public Domain.
 *

USE_MIX(NEWTOY(mix, "m:d:l#r#", TOYFLAG_USR|TOYFLAG_BIN))
config MIX
  bool "mix"
  default n
  help
   usage: mix [-m mixer] [-d device] [-l level / left level] [-r right level]

   Lists/sets mixer devices/levels.
*/

#define FOR_mix
#include <linux/soundcard.h>
#include "toys.h"


GLOBALS(
   char *mixer;
   char *device;
   int level;
   int right;
)

void mix_main(void)
{

  const char *devices[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES;
  char *mixer_name=(toys.optflags & FLAG_m)?TT.mixer:"/dev/mixer";
  int i, mask, device=-1, level, mixer=xopen(mixer_name, O_RDWR|O_NONBLOCK);

  xioctl(mixer, SOUND_MIXER_READ_DEVMASK,&mask);

  if (!(toys.optflags & FLAG_d)){
    for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i)
      if (1<<i & mask) printf("%s\n",devices[i]);
    return;
  }else{
    for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i){
      if (!strcmp(devices[i], TT.device)){
        if (1<<i & mask) device=i;
        else return; //with error
        break;
      }
    }
  }

  if (-1==device)
    return; //with error

  if (!(toys.optflags & FLAG_l)){
    xioctl(mixer, MIXER_READ(device),&level);
    printf("%s:%s = %d\n",mixer_name,devices[device],level);
    //todo - handle left and right channels w/ bitops. if (level&0xff00)...
    return;
  }

  level=TT.level;
  if (!(toys.optflags & FLAG_r))
    level = TT.right | (level<<8);

  xioctl(mixer, MIXER_WRITE(device),&level);
  close(mixer);
}

Big issue is that GLOBALS() must be in the reverse order of the NEWTOY optstring, which makes for a segfault if -d is passed.
You can drop char *mixer_name and instead do:

Code: Select all

  int mixer = xopen(TT.mixer?TT.mixer:"/dev/mixer", O_RDWR | O_NONBLOCK);

(make sure to give mixer its own line, even if you don't add a separate "int" declaration.)
The "else return" in the loop can go; it catches a strict subset of cases of "if (-1==device) return;" because the break statement would leave the loop with device still set to -1.
Properly all the ints in GLOBALS() should be longs.
And I thought that the mixer ioctls took a (unsigned?) short not an int, which could explain why I can't get this to reset vol on my system...

[technosaurus]

(make sure to give mixer its own line, even if you don't add a separate "int" declaration.)
The "else return" in the loop can go; it catches a strict subset of cases of "if (-1==device) return;" because the break statement would leave the loop with device still set to -1.
Properly all the ints in GLOBALS() should be longs.
And I thought that the mixer ioctls took a (unsigned?) short not an int, which could explain why I can't get this to reset vol on my system...

Thanks for the pointers. I still don't have the toybox inner workings down and still learning ioctl() (its powerful and applies to all sorts of interfaces but not well documented outside the kernel source).
I was hoping the int vs short wouldn't make a difference so long as the values were withing the short range, but I continue to learn new stuff about C all the time. Even after I think I have got my code pretty damn good, Rob ends up doing a cleanup pass that makes me blush.

I wonder if we could maintain extra toys that are not a good fit for standard toybox in an toys/extras directory, the build system already does toys/*/*.c, so having an extra directory of sane-but-non-standard tools would be fairly simple, but I'd like to look into the mechanism for adding $extralibs for things like tinyx11 or eventually xcb. I'd like to do xvesa/xfbdev, a terminal emulator and a window manager at a minimum (enough to get to a working "desktop")

Would anyone be interested in using goingnut's (permissively licensensed) mazewm to replace jwm and possibly adding support for stb_img and maybe libsvgtiny (from netsurf)??? Another route would be to have separate/interchangeable xcb based apps for window manager, pager, menu, deskop, tray, etc... mcwm is a good starting point for that path and the dwm/i3 projects have much of the rest.

[technosaurus]

mix is working:

Code: Select all

/* mix.c - A very basic mixer.
 *
 * Copyright 2014 Brad Conroy, dedicated to the Public Domain.
 *

USE_MIX(NEWTOY(mix, "m:d:l#r#", TOYFLAG_USR|TOYFLAG_BIN))
config MIX
  bool "mix"
  default n
  help
   usage: mix [-m mixer] [-d device] [-l level / left level] [-r right level]

   Lists/sets mixer devices/levels.
*/

#define FOR_mix
#include <linux/soundcard.h>
#include "toys.h"


GLOBALS(
   int right;
   int level;
   char *device;
   char *mixer;
)

void mix_main(void)
{
  const char *devices[SOUND_MIXER_NRDEVICES] = SOUND_DEVICE_NAMES;
  char *mixer_name=(toys.optflags & FLAG_m)?TT.mixer:"/dev/mixer";
  int i, mask, device=-1, level,
      mixer=xopen(mixer_name, O_RDWR|O_NONBLOCK);

  xioctl(mixer, SOUND_MIXER_READ_DEVMASK,&mask);

  if (!(toys.optflags & FLAG_d)){
    for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i)
      if (1<<i & mask) printf("%s\n",devices[i]);
    return;
  }else{
    for (i = 0; i < SOUND_MIXER_NRDEVICES; ++i){
      if ((1<<i & mask) && !strcmp(devices[i], TT.device)){
        device=i;
        break;
      }
    }
    if (-1==device) return; //with error
  }

  if (!(toys.optflags & FLAG_l)){
    xioctl(mixer, MIXER_READ(device),&level);
    if (0xFF < level) printf("%s:%s = left:%d\t right:%d\n", mixer_name,
                             devices[device], level>>8, level & 0xFF);
    else printf("%s:%s = %d\n",mixer_name, devices[device], level);
    return;
  }

  level=TT.level;
  if (toys.optflags & FLAG_r) level = TT.right | (level<<8);

  xioctl(mixer, MIXER_WRITE(device),&level);
  close(mixer);
}

Edit: fixed wrong ! on FLAG_r test

[Ibidem]

It only sets vol for me if I pass -r and -l.
...
I think this line is wrong:

Code: Select all

if (!(toys.optflags & FLAG_r)) level = TT.right | (level<<8);

That means:
If only -l was passed (and TT.right is 0), set level to level<<8.

So, a question about the ioctl:
Does 100<<8 set left channel or right channel to 100?

Experimenting, I find that removing the negation of the test makes it work more as I expected.
Also, the test for whether to set or show should be "& (FLAG_l | FLAG_r)"

[Ibidem]

On a completely unrelated note, I finally put my "wpanet" service on github (under CC0).
http://github.com/idunham/wpanet
It just starts wpa_supplicant and wpa_cli, and uses the second to start dhcp at the right time.
I find that it works well for connecting to wireless (including how it handles flakey connections).

But it does not have any tools for configuration, especially for setting up the first wpa_supplicant.conf. If someone wants to write one, I'd appreciate it...as long as they don't add too much bloat.
As far as dependencies go:
not python, not perl; some versions I can think of include: Tcl/Tk, bash/ksh with select, sh with dialog/xdialog/?whiptail, or sh with gtkdialog[123].
A C frontend is also acceptable, if it doesn't drag in too many libraries.
The minimum functionality that would be needed is:
-Create new config file (with ctrl_interface=/var/run/wpa_supplicant )
-View networks (wpa_cli scan_results)
-Add network (from the list of scan results or otherwise; support open/wep/wpa)
-disconnect/reassociate
All of these except 1. can be done from wpa_cli.

[technosaurus]

It only sets vol for me if I pass -r and -l.
...
I think this line is wrong:

Code: Select all

if (!(toys.optflags & FLAG_r)) level = TT.right | (level<<8);

That means:
If only -l was passed (and TT.right is 0), set level to level<<8.

So, a question about the ioctl:
Does 100<<8 set left channel or right channel to 100?

Experimenting, I find that removing the negation of the test makes it work more as I expected.
Also, the test for whether to set or show should be "& (FLAG_l | FLAG_r)"

Here is the rundown as I understand it:
Some devices don't have a left and right channel, for those (or if you want to set both channels with a precalculated short value) the -l flag means "level" vs "left" in the absence of a -r

If the -r flag _is_ passed (yes the `!` was probably an oversight, its not in my local version - will edit my post) the the -l means left channel which is the MSByte of a short and the -r value is the right channel which is the least significant byte of a short (thus the bitwise shift by 8 and the OR).
Although the values are short, Linux syscalls always take and return longs whether it be a pointer, integer type, or string ... the conversion is handled by the libc (I have a working syscall implementation if you want to see how it works)

The flag -r should not be passed without -l, so the (FLAG_l | FLAG_r) ... unless I add another option for just value such that -l always sets the MSB and -r always sets the LSB if passed individually and the -v (or whatever) sets the entire value from 0 to max unsigned long which could work for setting l and r simultaneously or to workaround strange behaviors one might encounter - currently this is how -l without a -r is supposed to work.

... need to see if
a) toybox already has a way to dissallow one flag without the other
b) use the existing value to allow changing only -r or -l like:???
- -l: level = (level & 0xFF) | (TT.level<<8)
-r: level = (level & 0xFF00) | (TT.right)
-v: level = TT.value