4.1 Alpha 4

[Martin]

My Dell laptop needs a "real" i810 xorg driver to display its native 1024x768 like was in Puppy 3.1.

lrwxrwxrwx 1 root root 12 2008-07-17 15:46 i810_drv.so -> intel_drv.so
-rwxr-xr-x 1 root root 307156 2007-11-28 20:42 intel_drv.so

The current i810_drv.so is a symlink to the intel driver which simply does not work at any resolution with xorg on this machine.

With xvesa, only 640x480 resolution is available and Puppy is virtually unusable at that resolution since many windows don't have slider bars.

My (and others) workaround is to copy the i810 driver from Puppy 3.1 but with a future kernel that may not work anymore.

Barry, can this be fixed?

Yup, same problem here with my Compaq D510 USDT

[HairyWill]

my intel 830m card doesn't work with the intel driver either
the vesa driver does work with my screen 1024x768
as does xvesa

[BarryK]

Barry,
I fixed the pupdial and modemprobe problems I reported in my previous posting. I attach a dotpet that fixes both and allows anyone else to test it. (Updated with improved implementation.) The changes I made are shown here as diff results:

Code: Select all

# diff pupdial /usr/sbin/pupdial 
11a12
> #RE v4.05: Move initialization of 4 variables; replace /dev/modem with its target device; protect "eval" from disruption by special characters inside the INFO variable, which is used only inside the dialog.
33a35,40
> #v4.05 Initialize these regardless of wvdial.conf existence.
> ynSTUPID_MODE1=no
> ynSTUPID_MODE2=no
> ynAUTO_RECONNECT1=yes #default is on.
> ynAUTO_RECONNECT2=yes #default is on.
> #v4.05 end
38a46,51
>  #v4.05 Substitute /dev/modem target for /dev/modem
>  if [ "`grep '/dev/modem' /tmp/wvdial.conf`" != "" -a -h /dev/modem ];then #modem = /dev/modem & it exists
>   echo "s/\/dev\/modem/\/dev\/`readlink /dev/modem`/g" > /tmp/pupdialsedscript
>   sed -i -f /tmp/pupdialsedscript /tmp/wvdial.conf #replace device in-place
>  fi
>  #v4.05 end
370,371c383
< RETSTRING="`echo "$RETSTRING" | grep -v '^ENTRYINIT2M=' | grep -v '^ENTRYINIT1M='`"
< 
---
> RETSTRING="`echo "$RETSTRING" | grep -E '^CHECK|^ENTRY[AB]|^yn|^EXIT'`" #v4.05 omit ENTRYINIT?M and INFO variables
#

Code: Select all

# diff modemprobe /usr/sbin/modemprobe 
22c22
<  ln -sf $xDEVM /dev/modem
---
>  [ "$xDEVM" != "modem" ] && ln -sf $xDEVM /dev/modem #v4.05 change link only if not already correct
# 

I hope you can include them in the next test release and have annotated them appropriately. Thanks.

The situation is that wvdialconf apparently checks devices /dev/modem and tty(anything), so always tests /dev/modem first - it actually tests its target, effectively testing the current device first, then others (in alphanumeric order) only if that fails. Pupdial and modemprobe will now handle that by showing the user the target device instead of "modem".

Richard

EDIT: I forgot to mention what behavior to expect. I think Barry warned us that a serial modem would not be automatically detected, but that the user must "probe" for it. The initial pupdial dialog box presents that as the only option, if no other type of modem is detected.

Afterthought: Since whatever device is linked-to by /dev/modem is the first to be tested by wvdialconf (modemprobe), merely changing /dev/modem to point to another device -- say, USB in response to a hotplug -- and re-probing would change the current modem to be that new device. What to do when the USB modem is unplugged is another issue TBD.
R

EDIT 7/24: I have replaced the fix with an improvement. It sets the config file to the target, instead of merely modifying the pupdial display. This is consistent with the practice of having wvdial.conf always specify the actual device, not /dev/modem.

In addition, I have corrected the problem where "command not found" messages occur after probing with pupdial, when running from the command line. No other impact.
Richard

Richard,
in the last couple of days I have made major changes to analog modem detection and setup.
I'll have a look at your mods, it looks like it is relevant, that is, things I have not yet fixed, like that missing commands error message.

[Flapdoodle]

Thanks ttuuxxx, I love your new blinky!

[cthisbear]

BK...take a bow.

I have a new Dell Vostro 1510 to resetup...clean out,
and put a few programs in XP on it.
It came pre-installed with XPPro.

I have been very happy with puppy 4 Dingo and Marks
Minisys Muppy 08.....given copies to my local computer
shop...and he now uses Puppy to clean Windows machines etc.

But Mr Dell changed specs....how unusual...and both of
those previous Pups booted....but couldn't see the hard drive...
even when I changed the Bios to ATA....not many options
with MR Dell.

The Toyota expletive was heard..........B****r.

What to do. Did a quick linux search.....didn't feel like
Ubuntu....though I see that you have had a play in it....
nothing wrong with that if you come up with a Puppy fix..
so downloaded Puppy 4.1 Alpha 4........relief..applause..
auto mounts?....made my day as the flu has handicapped
me at present.

Anyway smiles all round from me....no pics I'm afraid...
my face wouldn't even make it to radio.

No doubt I'll have to send you a small donation for a cuppa and cake.
And I'll have to burn another CD to my Chinese computer shop.

Worth it though.
Thanks again for allowing me to fix hardware and software
problems so much easier.

Again take a bow...you and those that send you fixes
and suggestions....the Linux Olympics champs.

Regards.............Chris.

[dogone]

Despite the many hours spent enhancing and tuning Event Manager and device handling, I find I still prefer Barry's 4.0 solution. It's simple, very intuitive and "just works". It's also spoiled me, as I now prefer to un-mount devices when I'm done with them.

Event Manger's flexible approach has potential, but EM's options are presently numerous and confusing. I'd like to see the entire matter re-thought in light of 4.0's simpler approach.

If you have an opinion in this regard, please speak up. Barry needs the feedback..

[ttuuxxx]

Thanks ttuuxxx, I love your new blinky!

your welcom I also have a white one I included in my latest icewm package http://www.murga-linux.com/puppy/viewto ... 412#218412

As for 4.1 alpha 4 I'll try it out tonight, The auto-mount sounds really interesting.

ttuuxxxx

[rerwin]

Barry,
Thanks for mentioning my modem work in your blog. I have a further request of you regarding modems.

Since wvdialconf probes modems based on the presence of their device nodes, the unavoidable presence of devices ttyLT0, ttyS_ESS0 and ttyS_PCTEL0 in the /dev directory can cause wvdialconf to "find" the wrong modem device. Even if I remove them from a fresh puppy with no modems (and save to a file), they reappear during the next boot-up.

Particularly, if the modem is actually a PCTEL or LT, probe "finds" ttyS_ESS0 instead of the correct device. Is it really necessary that those three devices always be present? Some modems appear to install their device node only if the driver is loaded. Could those ttyS_... (and ttyLT0) devices be removed from /dev and only placed there only if their driver gets loaded? If they must all be predefined, could they go into a subdirectory, so we could selectively create a softlink to the active one? (That would be similar to how the USB modems have to be handled.)

EDIT: Similarly, when probing for an actual serial modem, Probe shows it as ttyLT0!

And a final question: Have you gotten the martian modem driver to work? My Lucent modem does trigger loading of martian and copying of its script to /etc/init.d, but the device (ttySM0 or apparently anything we choose) is absent from /dev; the modem is not detected and does not perform. Any suggestions?

EDIT: More info re martian/LTmodem: I tried my Lucent modem and changed the device in the script from ttySM0 (not present) to ttyLT0 (present in /dev). That didn't appear to help, because the daemon reports a problem (in /var/log/messages):

Jul 26 23:30:39 (none) user.info kernel: martian loaded - 20080617

Jul 26 23:30:39 (none) user.info kernel: martian: added device 11c1:442 BaseAddress = 0xcc00, CommAddres = 0xd000, irq = 18
Jul 26 23:30:39 (none) user.info kernel: ACPI: PCI Interrupt 0000:00:02.7[C] -> GSI 18 (level, low) -> IRQ 18

Jul 26 15:30:42 (none) daemon.err martian: error: dynreloc: /proc/self/exe: no symbols
Jul 26 15:30:42 (none) daemon.err martian: error: Failed to link to driver
Jul 26 15:30:42 (none) user.info kernel: martian_modem is detached

Thanks.
Richard

[Sit Heel Speak]

Event Manger's flexible approach has potential, but EM's options are presently numerous and confusing. I'd like to see the entire matter re-thought in light of 4.0's simpler approach.

If you have an opinion in this regard, please speak up. Barry needs the feedback..

Agree with the "numerous and confusing" part. 4.00-k2.6.21.7 with the simpler Hotpup-style control interface is the happy medium. It needs a button in the control interface to mount/unmount all fixed storage device partitions at once (except don't unmount the /mnt/home partition if used, and leave the swap partitions alone). It also needs to gain the ability to see true scsi drives. It also needs to not show ghost partition icons if the drives-arrangement and/or partitioning get changed. With these three improvements I see it as the way forward for Puppy.

[dogone]

Hi Guys
@@@ UPDATED BLINKY @@@...I guess an alpha place would be a great place to test it out. ttuuxxx

ttuuxxx,
My own first impressions of the new blinky are very positive, but one aspect can be improved. I'm sure we'd all agree that tracking both incoming and outgoing net data is important. It's certainly an important distinction when it comes to security. The color gradation in new blinky blurrs this distinction a bit too much for my taste (suggests there's something in between "in" and "out"). Would you consider eliminating the color gradient and/or making it and the color scheme user configurable?

[BarryK]

Despite the many hours spent enhancing and tuning Event Manager and device handling, I find I still prefer Barry's 4.0 solution. It's simple, very intuitive and "just works". It's also spoiled me, as I now prefer to un-mount devices when I'm done with them.

Event Manger's flexible approach has potential, but EM's options are presently numerous and confusing. I'd like to see the entire matter re-thought in light of 4.0's simpler approach.

If you have an opinion in this regard, please speak up. Barry needs the feedback..

The Event Manager is totally configurable (or is supposed to be, if all the checkboxes work as intended) and can be rolled back to behave exactly as per 4.0.

[BarryK]

Barry,
Thanks for mentioning my modem work in your blog. I have a further request of you regarding modems.

Since wvdialconf probes modems based on the presence of their device nodes, the unavoidable presence of devices ttyLT0, ttyS_ESS0 and ttyS_PCTEL0 in the /dev directory can cause wvdialconf to "find" the wrong modem device. Even if I remove them from a fresh puppy with no modems (and save to a file), they reappear during the next boot-up.

Particularly, if the modem is actually a PCTEL or LT, probe "finds" ttyS_ESS0 instead of the correct device. Is it really necessary that those three devices always be present? Some modems appear to install their device node only if the driver is loaded. Could those ttyS_... (and ttyLT0) devices be removed from /dev and only placed there only if their driver gets loaded? If they must all be predefined, could they go into a subdirectory, so we could selectively create a softlink to the active one? (That would be similar to how the USB modems have to be handled.)

EDIT: Similarly, when probing for an actual serial modem, Probe shows it as ttyLT0!

And a final question: Have you gotten the martian modem driver to work? My Lucent modem does trigger loading of martian and copying of its script to /etc/init.d, but the device (ttySM0 or apparently anything we choose) is absent from /dev; the modem is not detected and does not perform. Any suggestions?

EDIT: More info re martian/LTmodem: I tried my Lucent modem and changed the device in the script from ttySM0 (not present) to ttyLT0 (present in /dev). That didn't appear to help, because the daemon reports a problem (in /var/log/messages):

Jul 26 23:30:39 (none) user.info kernel: martian loaded - 20080617

Jul 26 23:30:39 (none) user.info kernel: martian: added device 11c1:442 BaseAddress = 0xcc00, CommAddres = 0xd000, irq = 18
Jul 26 23:30:39 (none) user.info kernel: ACPI: PCI Interrupt 0000:00:02.7[C] -> GSI 18 (level, low) -> IRQ 18

Jul 26 15:30:42 (none) daemon.err martian: error: dynreloc: /proc/self/exe: no symbols
Jul 26 15:30:42 (none) daemon.err martian: error: Failed to link to driver
Jul 26 15:30:42 (none) user.info kernel: martian_modem is detached

Thanks.
Richard

4.1 is supposed to create any extra /dev nodes on-the-fly as needed, but I think currently that is only working for hotplug devices.

Hmmm, what I might do is leave those devnodes out of the default /dev, so they won't be there. Then, after 4.1alpha5 is released, if we find those devnodes are not getting created, I can mess with the pup_event_backend scripts and fix that.

[aragon]

hi barry, hi puppians,

as i don't know where to put this, i put it here, as it is related to kernel-questions for new versions.

as a user of puppy (actual 4.00) i found the intel-tool powertop

http://www.murga-linux.com/puppy/viewtopic.php?t=31290

as in the post mentioned, i don't know exactly what it is. now, a bit later, i tried it out once more. it seems to me, that it gives recommendations on how to compile the kernel to have a better power-usage on laptops.

I ran it and post the recommendations here, so barry or so else might take a look at it (i'm not able to use the information with my actual skills). Ok, the tool recommends to use the following :

CONFIG_TIMER_STATS
CONFIG_NO_HZ
CONFIG_USB_SUSPEND
CONFIG_CPU_FREQ_GOV_ONDEMAND
CONFIG_HPET_TIMER

maybe this could be used to advance puppy-usage on laptops. maybe it is an idea that puppy-laptop-users use this tool and post the findings so that we could see if there are recommendations that apply to every/most laptops in use with puppy.

cheers
aragon

[dogone]

The Event Manager is totally configurable (or is supposed to be, if all the checkboxes work as intended) and can be rolled back to behave exactly as per 4.0.

Barry,
I certainly don't doubt your intentions, but the closest I can come to 4.0's Hot Plug behavior is having the partition mount and Rox appear. Closing Rox, I am not provided the option to un-mount the partition.

But what "I want" is less important than how the entire kennel feels. I invite all to share their feelings about the current Event Manager. We're stuck here without some input.

[brymway]

Trying to learn so I played around with 4.1.
Chembook CL-51 Laptop
Intel Pentium (R) M 1.50GHz
1018 MB RAM----1024x768 Xorg
md5sum check ok---burned using default options
I use Dingo for my everyday computing.


Things that are different:
the battery indicator reads a constant 79%. Never changes. This laptop has been plugged in all day and has a 100% charge, my frugal Dingo that I was running immediately before it said so. Ticked the box to use MUT and the application disappeared and I couldn't get pmount or mut back up. Don't know if you want to know what I tried and worked perfectly.

[BarryK]

The Event Manager is totally configurable (or is supposed to be, if all the checkboxes work as intended) and can be rolled back to behave exactly as per 4.0.

Barry,
I certainly don't doubt your intentions, but the closest I can come to 4.0's Hot Plug behavior is having the partition mount and Rox appear. Closing Rox, I am not provided the option to un-mount the partition.

But what "I want" is less important than how the entire kennel feels. I invite all to share their feelings about the current Event Manager. We're stuck here without some input.

That is one thing you can't get with 4.1. When you close a Rox window, you will not be asked if you want to unmount the partition -- you can only have that with Dougal's HotPup.
Some feedback I have got is that it is better not to be pestered by such a question when a Rox window is closed.
With 4.1, you have to right-click the desktop icon to unmount it, or use Pmount.
This is a case of being accustomed to one tiny implementation detail and being unnecessarily attached to it. It is picking at details while missing the overall picture.

[paulh177]

4.1a4 under WinXP/QEMU doesn't seem to be able to access "real" drives.
See my posts in this thread

paul

[dogone]

This is a case of being accustomed to one tiny implementation detail and being unnecessarily attached to it...

You are absolutely correct and I am not concerned. Still in alpha, Puppy 4.1 is already so superior in so many ways, such details are of little import.

I should mention that despite a long held belief that "alphas" are for testing only, I have used 404 Aufs almost exclusively these past weeks. 4.1 is going to be terrific, Barry. Take those vitamins and we'll see you briefly as you cruise through alpha 5 and into Beta-town.

[BarryK]

Regarding using Rox to unmount a partition as is done in HotPup, as I understand the way Rox works, it will only offer to unmount a partition that it has itself mounted.

Thus, in HotPup, if you use one of the desktop icons to mount the partition, fine, Rox can then unmount it.

However, if you use any other method to mount the partition, if you then open Rox on that partition, closing the Rox window then you will not get the offer to unmount it. So, Pmount, MUT, anything else, has a fundamental compatibility problem.

I also seem to recall problems with HotPup not updating it's mounted/unmounted status when a partition is not mounted or unmounted with Rox. Probably a mouse-over the icon would force it to update, but that is clumsy. HotPup could have a periodic loop that forces an update, again clumsy and inefficient.

After considering all the issues, I decided that the method used by HotPup is too restricted.

[Sit Heel Speak]

Can someone tell me, in the absence of glipper, how to paste the output of an rxvt command into a reply box in this forum,...if the browser has auto-scroll active, since the middle-mouse button simply produces a compass rose?

An error in PEM: if I insert a floppy disk, and mount it, then unmount it...it seems to unmount alright, at least it is not shown by df after being unmounted...but, the icon still shows it as mounted.