(old)Puppy Linux Discussion Forum

@gersen: try 'modprobe joydev' AND 'modprobe analog'

Running the full iso on a live cd - 2GB RAM, no hdd.

I remastered but the new cd did not have my rox preferences. I selected to include customisations for that pc when given the choice by the script.

panzerpuppy, thanks for the advice, didn't help unfortunately.

I've had some luck though, as a long shot I grabbed some old usb joysticks I had and what do you know they all worked with just joydev loaded:

Logitech Extreme 3d Pro, Saitek ST290 and even a Thrustmaster joypad.

Now I have to figure out why the Saitek X52 doesn't. Its the device I use all the time on X-plane.

Regards.

Edit
Just googled for X52 + kernel 2.6.30, turns out there's a bug in 2.6.30 which prevents recognition of the X52.

joydev: blacklist digitizers avoids recognition of Saitek X52
This bug is related to a bad commit to joydev which now blacklists x52
joysticks.(d07a9cba6be5c0e947afc1014b5a62182a86f1f1)

Guess I'll have to wait on next kernel

I successfully compiled and tested the latest Lucent (kernel-resident) modem driver, but withheld it because it supports the same hardware IDs as the "user-space" Lucent-Agere driver, dev_martian. However, for cases where the martian_dev driver fails to support a Lucent modem, ltmodem could be a fallback. I attach separate dotpets for the firmware update and for the driver itself.

I feel that the firmware update should be included in the bugfix, since the existing firmware would not work with the now-current (ltmodem) driver. The device name has changed to ttySV0 and the old ltserial module no longer exists, necessitating changes to the firmware and files firmware.dep.2.6.30.6, MODULESCONFIG, and 60-dialup-modem.rules. (See the pinstall.sh script.)

I also feel that the driver should NOT be included in Puppy 4.3.1, but should be added to the repository, for users to install as a "last resort" to getting a Lucent/Agere modem working.
Richard

NOTE: As it stands, the firmware dotpet retains the old blacklisting of ltserial-now-ltmodem. That was done to allow the preferred driver, martian_dev, to be loaded, since both drivers were present in Puppy. This is appropriate if Barry were to include ltmodem in 4.3. But for users installing the dotpet, they also must un-blacklist ltmodem in BootManager, as well as then "probe-Erasing" the ttySM0 device selection (in PupDial) and rebooting. If Barry leaves the driver dotpet for the user to install from the repository, I would suggest that the blacklisting be removed (from MODULESCONFIG). That way, the driver dotpet would "just work" when installed.

UPDATE 10/10/09: I have now attached a better version of the firmware update (-2) that eliminates the need to un-blacklist the driver. This is consistent with my recommendation to provide the driver only as a downloadable package and to not build the driver into the Puppy distros.
Richard

I have set up an issue tracker on google code for versions 4.4+ and am looking for some volunteers who follows this thread and the bugs forum in general to enter issues into the tracker. (also has project hosting if you are working on any puppy projects or if you would like to be a package maintainer for your favorite programs and keep them up to date)

rerwin wrote:I successfully compiled and tested the latest Lucent (kernel-resident) modem driver........
Richard

Thank you Sir.

When you added a word in the spell check in previous versions, that word would be OK in the spell check when the document was next opened. This is not happening in 4.3.
The file that held the added words in 4.2 was /root/.config/enchant/.en_AU.dic (or en_US.dic). Does any one know what file is applicable (if any) in puppy 4.3?

Regarding he Lucent driver: EZ4arabs reports too me that his Thinkpad R22 with that driver finds the Lucent modem as ttyS4! That is interesting news and is probably related to the new standard driver, martian_dev's, inability to support it correctly. This is a new development, to me. My Lucent PCI modem gets ttySV0, which is what I expect from what I have read. So, be prepared for this surprise, if you need the driver.
Richard

Further thoughts about this development: My guess is that the Lucent driver refused to support EZ4arabs' modem, but blocked martian_dev from loading. Probing in pupdial then finds the serial modem. I would think we would get the same effect by leaving out the Lucent driver and blacklisting martian_dev (in BootManager). If that works, I can probably make a rule to disable martian_dev for this particular modem.

EZ4arabs, could you test this idea? Simply boot a fresh puppy (pfix=ram), Go into BootManager and blacklist martian_dev, "probe-ERASE" in pupdial, reboot. I would expect no modem to be detected. Then probe for the modem in pupdial. If this works, it will lead to an elegant solution to your problem. Thanks.
Richard

rerwin,

Running the full iso (pup-430.iso) on a live cd - 256MB RAM, no hdd.

Thanks, your modem compilations work fine with my pci conexant modem - vendor: 14f1 device: 2f00 using module hsfpcibasic2. Wvdial reports connection at impossibly fast speeds but it actually connects at the same speed as my 3com external - c.40kb/s.

I'm trying to remaster a slimmer iso. What's the minimum I would need from zp430305.sfs for my modem?

zygo,
I am in a rush now, but this should be all you need:
/lib/modules/2.6.30.5/hsfmodem/
/lib/modules/all-firmware/hsfmodem.tar.gz
Richard

I may have found why pup-430 wastes some of my loop devices.
Here is my BOOTCONFIG:EXTRASFSLIST is correct. PREVUNIONRECORD and LASTUNIONRECORD look wrong since they include "my-apps.sfs" and "wx_cb.sfs", both of which are squashfs version 3, for use by puppy412 and puppy421.
They are also in /initrd/tmp/EXTRASFSS: I suspect that pup-430 is attempting to mount these as loop devices, when this fails the loop devices remain attached to these files.

gyro

rerwin wrote: EZ4arabs, could you test this idea? Simply boot a fresh puppy (pfix=ram), Go into BootManager and blacklist martian_dev, "probe-ERASE" in pupdial, reboot. I would expect no modem to be detected. Then probe for the modem in pupdial. If this works, it will lead to an elegant solution to your problem. Thanks.
Richard

I had the same idea yesterday before reading your request and when I saw the result I was going to post it here but I said to myself rerwin will definitely" say what are you doing man,stop wasting my time? there is something wrong with your modem or you did something wrong."
here is what pupdial found:

Scanning your serial ports for a modem.

Port Scan<*1>: Scanning ttySV0 first, /dev/modem is a link to it.
ttySV0<*1>: ATQ0 V1 E1 -- OK
ttySV0<*1>: ATQ0 V1 E1 Z -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK
ttySV0<*1>: Modem Identifier: ATI -- LT V.92 Data+Fax Modem Version 8.30
ttySV0<*1>: Speed 4800: AT -- OK
ttySV0<*1>: Speed 9600: AT -- OK
ttySV0<*1>: Speed 19200: AT -- OK
ttySV0<*1>: Speed 38400: AT -- OK
ttySV0<*1>: Speed 57600: AT -- OK
ttySV0<*1>: Speed 115200: AT -- OK
ttySV0<*1>: Speed 230400: AT -- OK
ttySV0<*1>: Speed 460800: AT -- OK
ttySV0<*1>: Max speed is 460800; that should be safe.
ttySV0<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK

Found a modem on /dev/ttySV0, using link /dev/modem in config.
Modem configuration written to /etc/wvdial.conf.

my reaction was
wait.....to add more confusion to an already confused newbie here is what dmesg reports:

ltmodem: module license 'mixed' taints kernel.
Disabling lock debugging due to kernel taint
ltmodem loaded
ungrab-serial: detaching 11c1:45c from serial
serial 0000:00:03.1: PCI INT A disabled
e100: eth0: e100_probe: addr 0xfc020000, irq 11, MAC addr 00:03:47:90:27:51
ltmodem 0000:00:03.1: PCI INT A -> Link[LNKC] -> GSI 11 (level, low) -> IRQ 11
IRQ 11/ltmodem: IRQF_DISABLED is not guaranteed on shared IRQs
martian: core vars:
martian: s_x82 = 8086
martian: s_x84 = 2205
martian: s_x86 = 45c
s_x88 = 11c1
martian: x_dsp_mars = 0
martian: x_dsp_mars3 = 3
martian: BaseAddress = 6272
martian: ComAddress = 0
martian: Irq = 11
martian: S[0x7e] = 160
ttySV0 at I/O 0xf0000000 (irq = 0) is a VUART
martian: added device 11c1:45c BaseAddress = 0x1880, CommAddres = 0x0, irq = 11

I did blacklist martian and what you compiled was ltmodem so what martian core vars is doing there and does [VUART) stands for virtual uart?
it would be interesting to see what will happen if it was tried by Diamond in this thread:
http://www.murga-linux.com/puppy/viewto ... 80&t=46613

Thank you Sir for your time and help.

Problem is with the line of code at around line 1223 of "init" in "initrd.gz". The linefinds file names that contain ONEBASE as a substring, as well as the one that is identical. This is a problem when you have two files with names like "xxxx.sfs" and "xxxx-sfs4.sfs". grep matches "xxxx.sfs" to the leading "xxxx-sfs" in "xxxx-sfs4.sfs", so "xxxx.sfs" gets written to "/tmp/EXTRASFSS" when it should not be.
The simple solution is to change the line to But this still results in the sfs files being mounted in the order of the "ls -1 $SFSSDIR/*.sfs" command rather than the order specified in EXTRASFSLIST. So my suggested fix is to replace with gyro

hiveman wrote:Thanks for the advice on how to clean my mouse. Unfortunately that doesn't apply to my situation. The Dell Inspiron 8200 is a laptop - one of the older laptops that offer both a touchpad and and eraser-style pointer. Just for grins I did pull out a ps/2 external mouse, but that doesn't make any difference. The pointer still disappears every few minutes....

@hiveman,
I don't think this problem has any connection to mouse or touchpad. It sounds like the "invisible cursor" problem I've seen on a number of machines with shared video ram. The fix for that is to edit xorg.conf and uncomment the option for software cursor. I've been campaigning for a simple check box in xorgwizard, and some text to describe the problem, for some time. It doesn't always show up, even on the same model of machine, because it depends on the size and speed of the shared memory.

Like some other people with the EeePC I have also had problems with the audio mixer shown in the jwm tray on my ASUS EeePC 900A. I haven't described it before, because we were still dealing with more serious things, like fan control and possibly burning processors. I'll wait until 4.3.1 stabilizes before tackling this specialized problem.

The Xandros system which came installed is really slow, but it does have exactly the right mixer, with controls for both volume and microphone. The sound quality when using Skype and a headset with microphone is excellent. Under 4.3 I've never gotten the microphone adjusted properly, even after following posted advice about using alsamixer. If we could use that mixer supplied with the machine I would be happy. Anyone know how it works? I'm not familiar with Xandros, and ASUS has hidden a number of proprietary things on the EeePC.

Right now I'm on a Dell D610, with the Broadcom 5751 gigabit ethernet adapter for wired connections and the Intel 2915ABG adapter for wireless. 4.3, and the RCs for 4.3.1 work nicely here, with one real irritation: sometimes the network interfaces come up with the Broadcom as eth0 and the Intel as eth1, and sometimes they are the other way round. This causes the automatic wireless reconnection to fail even though it was set up correctly and nothing else has changed.

I'm guessing this is due to the order in which the modules load, not necessarily a problem with the networking wizard.

When the Mozilla browser's file manager window is opened it goes off screen (Firefox, Seamonkey 1.1.18 and 2.0).

With Opera it's ok.

Ongoing report of issues observed in 431 RC2 (frugal) on c.2004 Athlon-based desktop (frugal) and/or c.2000 Intel P4-based laptop (CD).

4. SQLiteManager "freezes" after selecting Tools/Options.

3. Bootmanager loading or unloading of SFS files still resets desktop icons!

2. No compatible modules found by CPU Frequency Scaling Tool. Compatible modules are found for both systems under Puppy 430.

1. No ROX menu entry for Partview app (found button at left of panel). Note also that "free" figures returned by Partview do not agree with those returned by df command. Differences range between 10% and 45%. I also suggest Partview *not* employ "alert" color red.

I was wondering if you could add support for Intel WiFi 5100AGN right out of the box? Setup seems to be a hassle for me

exProphecy
can you be more specific?

Barry updated the wifi firmware in Puppy 4.3, and all Intel firmwares are now included.
For the 5000 series devices Puppy now contains both the older and newer firmwares:
iwlwifi-5000-1.ucode
and
iwlwifi-5000-2.ucode

What does the "dmesg" command tell you after bootup?