Does sound work in Puppy 3.01/302? Dingo alpha7 is using the same kernel and sound drivers, so if it doesn't work in alpha7 then it probably doesn't work in 3.0x. In which case you need to wait for a release with later alsa sound drivers -- probably when I release Dingo with the 2.6.25 kernel.changturkey wrote:Sound works in Alpha 6, not Alpha 7, used command alsaconf to configure soundcard, here is some info.
Code: Select all
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c) 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 0c) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Contoller #4 (rev 02) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02) 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8400M GS (rev a1) 03:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05) 03:01.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 03:01.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12) 03:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 03:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express (rev 02) 0c:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
Dingo alpha7 feedback/bugs
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
[url]https://bkhome.org/news/[/url]
-
- Posts: 138
- Joined: Sat 06 Oct 2007, 11:58
Dingo alpha7
It looks like Barry has not uploaded the "gettext-0.16.1" as package manager can not install it.
Booting entirely into RAM from a CD. Here are some observations of this alpha release.
Dialup disconnects after 2 seconds. The /root/.etc/ppp/chap-secrets and /root/.etc/ppp/pap-secrets workaround seems to fix it.
I boot from a CD in an internal DVD reader (/dev/hdc) and I have an internal DVD rewriter. In the CD/DVD drive Wizard all the settings are on /dev/hdc and I can set them all to /dev/hdd but it will not retain my DVD reader setting.
cdp is missing.
xine takes 20-30 seconds after the button is clicked before it makes any sound from an audio CD. During this time the disk is spinning. This drive worked much quicker in 301. I tried starting xine after replacing the boot CD with the audio CD but then the xine window title says 'There is no MRL'. Even when I put the Puppy cd back into /dev/hdc.
The volume control in the panel has no effect on the sound coming from xine.
Dialup disconnects after 2 seconds. The /root/.etc/ppp/chap-secrets and /root/.etc/ppp/pap-secrets workaround seems to fix it.
I boot from a CD in an internal DVD reader (/dev/hdc) and I have an internal DVD rewriter. In the CD/DVD drive Wizard all the settings are on /dev/hdc and I can set them all to /dev/hdd but it will not retain my DVD reader setting.
cdp is missing.
xine takes 20-30 seconds after the button is clicked before it makes any sound from an audio CD. During this time the disk is spinning. This drive worked much quicker in 301. I tried starting xine after replacing the boot CD with the audio CD but then the xine window title says 'There is no MRL'. Even when I put the Puppy cd back into /dev/hdc.
The volume control in the panel has no effect on the sound coming from xine.
Geany print problem - easy fix
After using CUPS to set up printer, trying to print from Geany says it
will use: /usr/bin/lpr - but lpr is a dead link to lpr-cups
Replace it with a link to lpr_cups and Geany prints.
Note: when you first enter Puppy 3.97 lpr is a small script but when
you invoke CUPS lpr gets changed to the dead link.
GeoW
will use: /usr/bin/lpr - but lpr is a dead link to lpr-cups
Replace it with a link to lpr_cups and Geany prints.
Note: when you first enter Puppy 3.97 lpr is a small script but when
you invoke CUPS lpr gets changed to the dead link.
GeoW
xorgwizard resolution fixes not added to alpha7
Barry,
I created an alpha6 fix for xorgwizard with my report of issues quoted below. Since it was skipped, I have merged the xorgwizard changes into the aplha7 xorgwizard. The result is attached along with a difference listing. I have tested it successfully with both 3.98 and 3.02.
Those changes correct the video adapter signatures for Trident CYBER adapters, add two more of them, and insert the xorg.conf "PreferredMode" monitor parameter to ensure the selected resolution is set. The incorrect resolution may be related to either the new version of xorg or to RandR-enabled video drivers such as "intel".
Anyone can try this out by extracting the wizard to someplace easily accessible from the command prompt. Boot with pfix=nox, mount the location of the new xorgwizard file, then run it using the full path name. Then run xwin to finish bootup.
If already booted to the desktop, just exit to the command prompt, find and run the wizard as above, then xwin.
Richard
I created an alpha6 fix for xorgwizard with my report of issues quoted below. Since it was skipped, I have merged the xorgwizard changes into the aplha7 xorgwizard. The result is attached along with a difference listing. I have tested it successfully with both 3.98 and 3.02.
Those changes correct the video adapter signatures for Trident CYBER adapters, add two more of them, and insert the xorg.conf "PreferredMode" monitor parameter to ensure the selected resolution is set. The incorrect resolution may be related to either the new version of xorg or to RandR-enabled video drivers such as "intel".
Please consider updating the wizard from the attached archive to avoid resolution weirdness. Thanks.Posted: Mon Feb 11, 2008 8:03 pm Post subject: XorgWizard sets wrong resolution with new "intel" driver
Subject description: New driver supports RandR; ignores Puppy's resolution settings; uses non-listed 1152x864. Solved.
On my IBM NetVista PC with Intel 845 built-in graphics and an ADI 5P CRT monitor, the old driver, i810, set resolutions as directed by Puppy's xorgwizard in xorg mode. In alpha6 and the newer driver, intel, the resolution is set to 1152x864 no matter what I select (1024, 1280, 800) with the wizard. The resolution is reported by HardInfo and corresponds to what I see on the screen.
I found a post that suggests the solution:
http://www.mp3car.com/vbulletin/linux/1 ... fixed.html
It uses an xorg.conf Monitor-Section Option statement that affects only adapters that support RandR 1.2 (The X Resize and Rotate Extension) and is apparently ignored by other adapters. The man-page definition of it is:
Quote:
Option PreferredMode string
This optional entry specifies a mode to be marked as the preferred initial mode of the monitor. (RandR 1.2-supporting drivers only)
I have tried this Option using the same resolution as in the Screen Section and, indeed, the problem is corrected. I have modified /usr/sbin/xorgwizard to generate the Option statement with the same value as that placed in the Screen Section "Modes" statement. I have also tested the fix on other PCs (that don't need it) and there is no impact.
Anyone can try this out by extracting the wizard to someplace easily accessible from the command prompt. Boot with pfix=nox, mount the location of the new xorgwizard file, then run it using the full path name. Then run xwin to finish bootup.
If already booted to the desktop, just exit to the command prompt, find and run the wizard as above, then xwin.
Richard
- Attachments
-
- xorgwizard_for_3.98.tar.gz
- Xorgwizard with all reported problem-laptop video adapters and
resolution correction for RandR-supporting X-server drivers (e.g., intel). - (34.67 KiB) Downloaded 903 times
Pwget dialogs use incorrect/inconsistent term
The new pwget tool directs the user to "cut" out a web address and paste it, while all that is needed is to "copy" the URL to paste it. Pwget's instructions can be made more precise by the replacement of "Cut" with "Copy" in statements 12 and 29 of the script in /usr/local/Pwget.
My original report on this for alpha6 is here:
http://www.murga-linux.com/puppy/viewto ... 802#170802
Richard
My original report on this for alpha6 is here:
http://www.murga-linux.com/puppy/viewto ... 802#170802
Richard
xfdiff misses difference in very long statement/line
While verifying my minor changes to pwget with xfdiff, I discovered that my change on line 29 was not indicated. The same change on line 12 at character 16 of a ~130-char line was detected.
The line in question:The word "Copy" replaced "Cut".
Since xfdiff did not find the word or indicate the maximum line length it compares, its credibility is dubious. It cannot be trusted.
My evidence is the following diff listing and attached screeen capture showing both the text in question and xfdiff's omission of it. (I added a dummy change later in the file so that xfdiff would list the lines adjacent ot the long line.) The "<action> Xdialog" line should follow the ""<button help>" line, third from the bottom in both subwindows of xfdiff.
Richard
The line in question:
Code: Select all
<action>`Xdialog --wrap --screencenter --left --title "Pwget - HELP" --msgbox "Pwget is a simple front end to the wget utility. Wget is used for downloading larger files from the internet such as ISOs. The files are verified during the download procedure. As ISO and other files are checked and downloads resumed, they do not require a md5sum check. Copy and paste the source file you wish to download. Use the file selector to choose the destination. \n\n Lobster, Jan 2008" 600x0`</action>
Since xfdiff did not find the word or indicate the maximum line length it compares, its credibility is dubious. It cannot be trusted.
My evidence is the following diff listing and attached screeen capture showing both the text in question and xfdiff's omission of it. (I added a dummy change later in the file so that xfdiff would list the lines adjacent ot the long line.) The "<action> Xdialog" line should follow the ""<button help>" line, third from the bottom in both subwindows of xfdiff.
Richard
12c12
< <text><label>Cut and Paste URL location of required file into "Address". Add destination and click "OK"</label></text>
---
> <text><label>Copy and Paste URL location of required file into "Address". Add destination and click "OK"</label></text>
29c29
< <action>`Xdialog --wrap --screencenter --left --title "Pwget - HELP" --msgbox "Pwget is a simple front end to the wget utility. Wget is used for downloading larger files from the internet such as ISOs. The files are verified during the download procedure. As ISO and other files are checked and downloads resumed, they do not require a md5sum check. Cut and paste the source file you wish to download. Use the file selector to choose the destination. \n\n Lobster, Jan 2008" 600x0`</action>
---
> <action>`Xdialog --wrap --screencenter --left --title "Pwget - HELP" --msgbox "Pwget is a simple front end to the wget utility. Wget is used for downloading larger files from the internet such as ISOs. The files are verified during the download procedure. As ISO and other files are checked and downloads resumed, they do not require a md5sum check. Copy and paste the source file you wish to download. Use the file selector to choose the destination. \n\n Lobster, Jan 2008" 600x0`</action>
41c41
< done
---
> done #text added for dummy change rse
- Attachments
-
- xfdiff-pwget-error.png
- Geany and xfdiff and an omitted 500-character statement
- (85.61 KiB) Downloaded 1131 times
Unexpected directory for home/file icon and menu selections
While testing my xorgwiz fix at the command line before running xwin, I changed the current directory to my flash drive. After executing xwin and getting back to the desktop, I found that the "file" icon and ROX menu entry resulted in display of the contents of the flash drive, instead of the familiar /root directory. Other programs exhibit the same default directory. Apparently the "$@" parameter in the underlying scripts relies on the setting of the "current directory".
Unless this is an intended "feature," it can be remedied by having xwin ensure that the current directory is "~/". The following statement would accomplish that, inserted after line 9 of xwin for both 3.97 and 3.02, and similarly for other Puppy versions.
Richard
Unless this is an intended "feature," it can be remedied by having xwin ensure that the current directory is "~/". The following statement would accomplish that, inserted after line 9 of xwin for both 3.97 and 3.02, and similarly for other Puppy versions.
Code: Select all
cd ~/ #v3.98 Ensure current directory is root, in case changed at command prompt, so rox icon and menu item open only at home directory. rerwin
Last edited by rerwin on Sun 09 Mar 2008, 23:00, edited 1 time in total.
Richard - I think that could be good. But I suspect that would mean programs would start saving config files and stuff to whichever location you started X from, which would not be good, although it would be an intended feature, just not desirable for puppy. I will test it when I get home.
We had a discussion here about changing where the rox home icon takes you - there is a documented hack to the rox source that can change it, and my suggestion was to point it at ~/home, which can be a symlink to ~ so a user can replace it with a symlink to wherever they want - but nobody ever bothered recompiling ROX like this.
We had a discussion here about changing where the rox home icon takes you - there is a documented hack to the rox source that can change it, and my suggestion was to point it at ~/home, which can be a symlink to ~ so a user can replace it with a symlink to wherever they want - but nobody ever bothered recompiling ROX like this.
Re: assumed home directory
disciple,
Keep in mind that all of the programs invoked with the "$@" parameter are affected. So adapting ROX doesn't solve the entire problem.
Keep in mind that all of the programs invoked with the "$@" parameter are affected. So adapting ROX doesn't solve the entire problem.
OFF TOPIC
I'm surprised these incremental versions aren't being additionally offered via Xdelta patches (as opposed to only full-size ISOs), to really reduce the download time for the majority of users, who'll already have a previous alpha.
http://puppylinux.org/wikka/XdeltA
I'm surprised these incremental versions aren't being additionally offered via Xdelta patches (as opposed to only full-size ISOs), to really reduce the download time for the majority of users, who'll already have a previous alpha.
http://puppylinux.org/wikka/XdeltA
[size=75]- Remember: it's a [url=http://puppylinux.org/wikka/PuppyLinuxMainPage]wiki[/url]. You can contribute too! :D
- Puplet creators, see [url=http://puppylinux.org/wikka/DistributingYourPuplet]DistributingYourPuplet[/url][/size]
- Puplet creators, see [url=http://puppylinux.org/wikka/DistributingYourPuplet]DistributingYourPuplet[/url][/size]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Dingo alpha7
Fixed.charnisingh wrote:It looks like Barry has not uploaded the "gettext-0.16.1" as package manager can not install it.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
zygo wrote:Booting entirely into RAM from a CD. Here are some observations of this alpha release.
Dialup disconnects after 2 seconds. The /root/.etc/ppp/chap-secrets and /root/.etc/ppp/pap-secrets workaround seems to fix it.
What workaround is that?
Is there any application or script that needs that? Or is it just something that you yourself find a useful thing to have? I think it is small, I could put it in.cdp is missing.
Maybe I'll go back to Gxine, same as 3.01. Then at least Dingo will be no worse than 3.01.xine takes 20-30 seconds after the button is clicked before it makes any sound from an audio CD. During this time the disk is spinning. This drive worked much quicker in 301. I tried starting xine after replacing the boot CD with the audio CD but then the xine window title says 'There is no MRL'. Even when I put the Puppy cd back into /dev/hdc.
The volume control in the panel has no effect on the sound coming from xine.
I experienced a problem with Xine-ui a couple of days ago -- when I tested a VCD, clicking the "VCD" button on the GUI interface hung my computer.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Geany print problem - easy fix
Ah, running CUPS from the menu runs /usr/sbin/cups_shell, which has this in it:GeoW wrote:After using CUPS to set up printer, trying to print from Geany says it
will use: /usr/bin/lpr - but lpr is a dead link to lpr-cups
Replace it with a link to lpr_cups and Geany prints.
Note: when you first enter Puppy 3.97 lpr is a small script but when
you invoke CUPS lpr gets changed to the dead link.
GeoW
Code: Select all
#v2.17.1 PDQ print system has lpr symlink to /usr/bin/pdq, set in /usr/sbin/printerwizard.sh,
#so may have to change it back...
rm -f /usr/bin/lpr
ln -s lpr-cups /usr/bin/lpr
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: xorgwizard resolution fixes not added to alpha7
It's done. Thanks for that, especially the difference file so I was able to see quickly what you did.rerwin wrote:Barry,
I created an alpha6 fix for xorgwizard with my report of issues quoted below. Since it was skipped, I have merged the xorgwizard changes into the aplha7 xorgwizard. The result is attached along with a difference listing. I have tested it successfully with both 3.98 and 3.02.
Those changes correct the video adapter signatures for Trident CYBER adapters, add two more of them, and insert the xorg.conf "PreferredMode" monitor parameter to ensure the selected resolution is set. The incorrect resolution may be related to either the new version of xorg or to RandR-enabled video drivers such as "intel".Please consider updating the wizard from the attached archive to avoid resolution weirdness. Thanks.Posted: Mon Feb 11, 2008 8:03 pm Post subject: XorgWizard sets wrong resolution with new "intel" driver
Subject description: New driver supports RandR; ignores Puppy's resolution settings; uses non-listed 1152x864. Solved.
On my IBM NetVista PC with Intel 845 built-in graphics and an ADI 5P CRT monitor, the old driver, i810, set resolutions as directed by Puppy's xorgwizard in xorg mode. In alpha6 and the newer driver, intel, the resolution is set to 1152x864 no matter what I select (1024, 1280, 800) with the wizard. The resolution is reported by HardInfo and corresponds to what I see on the screen.
I found a post that suggests the solution:
http://www.mp3car.com/vbulletin/linux/1 ... fixed.html
It uses an xorg.conf Monitor-Section Option statement that affects only adapters that support RandR 1.2 (The X Resize and Rotate Extension) and is apparently ignored by other adapters. The man-page definition of it is:
Quote:
Option PreferredMode string
This optional entry specifies a mode to be marked as the preferred initial mode of the monitor. (RandR 1.2-supporting drivers only)
I have tried this Option using the same resolution as in the Screen Section and, indeed, the problem is corrected. I have modified /usr/sbin/xorgwizard to generate the Option statement with the same value as that placed in the Screen Section "Modes" statement. I have also tested the fix on other PCs (that don't need it) and there is no impact.
Anyone can try this out by extracting the wizard to someplace easily accessible from the command prompt. Boot with pfix=nox, mount the location of the new xorgwizard file, then run it using the full path name. Then run xwin to finish bootup.
If already booted to the desktop, just exit to the command prompt, find and run the wizard as above, then xwin.
Richard
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Pwget dialogs use incorrect/inconsistent term
Thanks, fixed.rerwin wrote:The new pwget tool directs the user to "cut" out a web address and paste it, while all that is needed is to "copy" the URL to paste it. Pwget's instructions can be made more precise by the replacement of "Cut" with "Copy" in statements 12 and 29 of the script in /usr/local/Pwget.
My original report on this for alpha6 is here:
http://www.murga-linux.com/puppy/viewto ... 802#170802
Richard
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: xfdiff misses difference in very long statement/line
Hmmm. Perhaps you could send an email to the author of xfdiff.rerwin wrote:While verifying my minor changes to pwget with xfdiff, I discovered that my change on line 29 was not indicated. The same change on line 12 at character 16 of a ~130-char line was detected.
...
Since xfdiff did not find the word or indicate the maximum line length it compares, its credibility is dubious. It cannot be trusted.
I sent him an email about 6 months ago informing of the patch-file-generation just crashing. No response. However, I did contact him once before that, with another difficulty and he did reply on that occasion. It has been a long time since he upgraded xfdiff, so he should be gently persuaded to do so.
[url]https://bkhome.org/news/[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Re: Unexpected directory for home/file icon and menu selecti
Yes, I can't think of any reason why we would want that as a feature, so I have implemented your change.rerwin wrote:While testing my xorgwiz fix at the command line before running xwin, I changed the current directory to my flash drive. After executing xwin and getting back to the desktop, I found that the "file" icon and ROX menu entry resulted in display of the contents of the flash drive, instead of the familiar /root directory. Other programs exhibit the same default directory. Apparently the "$@" parameter in the underlying scripts relies on the setting of the "current directory".
Unless this is an intended "feature," it can be remedied by having xwin ensure that the current directory is "~/". The following statement would accomplish that, inserted after line 9 of xwin for both 3.97 and 3.02, and similarly for other Puppy versions.RichardCode: Select all
cd ~/ #v3.98 Ensure current directory is root, in case changed at command prompt, so rox icon and menu item open only at home directory. rerwin
[url]https://bkhome.org/news/[/url]