Retrovol replaced with Aumix and Pnmixer
Retrovol is a combination audio mixer and tray applet. It has been working fine for me, until today.
Now that I am using a Radeon HD 6780 video card, suddenly Retrovol is
broken. The icon is sometimes in the tray, sometimes not. When not
displaying anything, there is still a space that responds to clicks.
Sometimes though, it dies completely. Even though it may respond to
clicks, the volume slider does not work.
A quick search on the Puppy Forum reveals that I am not alone;
http://www.murga-linux.com/puppy/viewtopic.php?t=97258
http://www.murga-linux.com/puppy/viewtopic.php?t=110613
What these people have not identified, is what video card they are
using. Given that I have been using retrovol for years on different PCs
and laptops without any problem, always Intel video, and suddenly broken
when I have changed to a AMD card, well, it is too much of a
coincidence.
So, Easy and Quirky have changed over to 'aumix' and 'pnmixer'. The former is a audio mixer, the latter a tray applet.
Which reminds me, my build of Quirky for the RPi had the same problem, retrovol was broken, and I used aumix and pnmixer.
OpenGL hardware acceleration for AMD video card
I have posted that only had software rendering for OpenGL, for my AMD/ATI BART Radeon HD 6870 video card:
http://bkhome.org/news/201712/amdati-barts-xt-radeon-hd-6870-card.html
I compiled 'mesa' in OpenEmbedded without 'llvm'. I wanted to avoid
llvm, due to it's size, as have done in some earlier pups. The problem
is that some of the AMD/ATI mesa drivers require llvm.
The mesa drivers that require llvm are: r300, r600, radeonsi
However, I did read that r600 can be compiled without llvm, by the configure options:
--with-gallium-drivers=r600 --disable-gallium-llvm
Not so r300 and radeonsi, they need llvm, apparently.
I determined that my video card needs the 'r600' driver. I decided to
include llvm, for the sake of others who might need the r300 and
radeonsi drivers.
llvm can be compiled in OE, however, it is not configured properly,
nor is mesa in OE configured properly -- for example, won't build the
r600 driver.
So, I have built llvm and mesa in a running Quirky Pyro64 (0.6.2).
The package 'elfutils' is required, can be installed from the PPM.
Here is how I compiled llvm, version 3.9.1 (with hints from LFS):
# mkdir build
# cd build
# CC=gcc
# CXX=g++
removed: -DLLVM_ENABLE_FFI=ON
# cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=ON \
-DLLVM_TARGETS_TO_BUILD="host;AMDGPU;X86" -Wno-dev ..
# make
# new2dir make install
Then mesa 17.0.2:
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu \
--enable-shared-dricore --enable-osmesa --enable-xa --enable-gallium-llvm --enable-shared-glapi \
--enable-glx-tls --enable-dri --with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast \
--with-gallium-drivers=r600,r300,radeonsi --enable-dri3 --enable-gles1 --enable-gles2 \
--enable-egl --enable-llvm-shared-libs --disable-omx-bellagio --enable-vdpau \
--with-egl-platforms='drm x11'
# make
# new2dir make install
There was some uncertainty here, what drivers to put into
"--with-dri-drivers" and "--with-gallium-drivers". I did what seemed
sensible, though it did seem that some, for example "i965", could be
moved to the latter. Some online examples have the drivers in both,
which seems odd.
Some of the options are auto-detected, however, putting them in
explicitly is good to check that the host has the required packages.
Yay, running 'glxinfo':
OpenGL renderer string: Gallium 0.4 on AMD BARTS (DRM 2.50.0 / 4.14.1, LLVM 3.9.1)
...that is, not using the "software rasterizing" anymore. I haven't
been able to give any TLC for NVIDIA video, will have to get hold of an
NVIDIA card to play with.
Intel and AMD video conflict
I reported yesterday about the result of plugging in my AMD Radeon HD6870 card:
http://bkhome.org/news/201712/amdati-barts-xt-radeon-hd-6870-card.html
Quoting:
Booting Easy Pyro64 0.6.4 from USB-drive, get a desktop. Fine, but 'glxinfo' reported software rasterising. Also, exit from X to commandline results in a blank screen. Also, under certain conditions, that I have not yet narrowed down, there is a hang at bootup.
My midi-tower PC also has on-board Intel video. There is a file, /etc/modeprobe.d/i915.conf containing this:
options i915 modeset=1
And /etc/modeprobe.d/radeon.conf, both with this:
options radeon modeset=1
I simply removed the i915.conf file, rebooted, and that fixed the exit-from-X-to-commandline, also bootup-to-commandline-no-X.
...er, but then I restored i915.conf, and exit-from-X-to-commandline, also bootup-to-commandline-no-X, are still fixed. Hmmm. The UEFI-Setup is showing on-board video as disabled ...the UEFI must have done that automatically? I don't know. There's too much that I don't know here.
This needs more testing, and rerwin's thoughts on this are also very helpful:
http://www.murga-linux.com/puppy/viewtopic.php?p=939428#939428
http://www.murga-linux.com/puppy/viewtopic.php?p=940531#940531
I will append to this post as I discover more.
AMD/ATI BARTS XT Radeon HD 6870 card
I purchased a second-hand midi-tower PC in May of this year:
http://bkhome.org/news/201705/bought-old-pc.html
It has on-board Intel video, but also came with an enormous AMD
PCI-bus video card, model BARTS XT, also known as Radeon HD 6870.
I removed the AMD card before first power-on, and never put it back.
However, testers of Easy/Quirky Pyro64 have reported issues with NVIDIA
and AMD video, so I decided to plug in my AMD card and test it.
Booting Easy Pyro64 0.6.4 from USB-drive, get a desktop. Fine, but 'glxinfo' reported software rasterising. Also, exit from X to commandline results in a blank screen. Also, under certain conditions, that I have not yet narrowed down, there is a hang at bootup.
This is actually "good news", as I am getting problems that testers have reported, so I have something to work with.
More info:
http://www.geeks3d.com/20101022/amd-radeon-hd-6870-launch-day-meet-barts-xt/
Yet another fan! Note, the HD 6870 was released late in 2010. Note also, I am using the HDMI output, not those big DVI sockets (I have never used DVI, know nothing about it).
Problems with JWM window manager
I have been using JWM 2.3.7 in recent builds of Quirky and Easy,
however, have encountered rather a lot of bugs. The most recent report
was choosing the "Move" option from the right-click menu in a window
title-bar crashing JWM -- which brings down all of X.
So, I have been compiling and testing the latest from github, but
this has not been smooth sailing, as I have reported to the Puppy Forum:
http://murga-linux.com/puppy/viewtopic.php?p=978446#978446
So, with revision 1675, ~/.jwmrc needs new <Mouse> tags, else
is broken. It looks like Joe will fix that, so it defaults to working
without those tags.
I keep thinking that I liked the old revision 976... it was pretty
rock solid. I hunted through the Pup Forum for any reports of bugs with
976...
666philb reported 976 fixed a bug:
http://murga-linux.com/puppy/viewtopic.php?p=801782#801782
Ah, I recall someone mentioned this one... Hesse James reported 976 cannot properly display additional vertical trays:
http://murga-linux.com/puppy/viewtopic.php?p=836688#836688
For the JWMDesk app, radky commented about an icon-sizing problem with vertical panels in 976:
http://www.murga-linux.com/puppy/viewtopic.php?p=869691#869691
Incidentally, radky is continuing to support older versions of JWM in his JWMDesk.
Precord updated to 9.0.3
Precord, an audio recorder and player, has been in all my Easy, Quirky, and earlier pups, for many years.
The author, mcewanw, has a thread on the Puppy Forum:
http://murga-linux.com/puppy/viewtopic.php?t=49907
I have just upgraded from version 8.1.4 to 9.0.3, and fixed a couple of small things, so my PET is 9.0.3-1.
It is not a good practice to have a hidden file in /etc, so I have changed /etc/precord/.precordrc to /etc/precord/precordrc.
Ditto, ~/.precord/.precordrc is now ~/.precord/precordrc
JWM does not display the icon, mini-record.xpm in the menu. It used to, but version 2.3.7 doesn't.
The reason is, it is actually a png file.
I have removed it from the PET, that is, removed
/usr/share/mini-icons/mini-record.xpm, as woofQ (used to build Easy and
Quirky) now has mini-record.xpm, an actual XPM image.
That's at rootfs-skeleton/usr/local/lib/X11/mini-icons/mini-record.xpm
in woofQ
My modified PET:
http://distro.ibiblio.org/easyos/noarch/packages/pet/pet_packages-noarch/precord-9.0.3-1.pet
One thing, the XPM image doesn't look quite as nice as the PNG.
gtk stock icons missing
Working on 01micko's Simple Samba Management and my QuickSamba scripts, I noticed that gtk stock icons are not displaying.
Then I tried Dropbox GUI file manager, created by mikeb:
http://murga-linux.com/puppy/viewtopic.php?t=90753
...however, none of the icons in the buttons display.
Dropbox GUI is great, it is good to see mikeb active on the Puppy Forum again.
Forum member SFR has created a patch for the gtk+ source, to restore the traditional icons:
http://www.murga-linux.com/puppy/viewtopic.php?p=847362#847362
...this patch still works on the latest gtk+, 2.24.31, so I plan to
recompile it in OpenEmbedded and see if that fixes the problem.
EDIT:
That patch did not fix anything. The solution was elsewhere. Dropbox-GUI is using code for gtkdialog like icon="gtk-network", which triggered a memory. Changing it to stock="gtk-network" fixed it.
However, icon-name="gtk-network" in the window tag is broken. Replacing icon-name with stock, icon, or stock-id
does not fix it. It actually has to be an icon in
/usr/share/icons/hicolor. So, I created
/usr/share/icons/hicolor/16x16/actions/gtk-network.xpm (symlink to
/usr/local/lib/X11/mini-icons/pc-2x.xpm, to save space). Now it works.
Note that stock="gtk-network" elsewhere in the gtkdialog xml code uses the gtk inbuilt icon, not the new one that I have created,
QuickSamba mounts remote shares
I posted yesterday about this new project:
http://bkhome.org/news/201712/quicksamba-one-stop-shop-for-sharing.html
It has progressed well, and I am now able to mount a share from Easy OS running on another computer.
01micko's Simple Samba Management has been modified somewhat. Here is a snapshot:
The default password is "woofwoof" and that displays in the password edit boxes. If the user changes the password, it displays as X's. Samba stores it in an encrypted form and it is not retrievable -- so you have to remember it, or you can change it at any time. The username and password is required when mounting the share from another PC.
QuickSamba uses smbnetfs to scan for remote shares. In my case, there is only one, with hostname EASYPC26578:
Click the "Mount Shares" button, the username and password is asked for, and it is mounted and becomes available:
Click on the folder button, and the remote share is available. Pretty simple.
There are a few more things to tidy up, and I hope to get this out as a Xmas present.