Recapitulating, Puppy-testers reported that their wireless keyboard/mouse was not working in the recent Woof-built alpha releases, although it does work in older versions of Puppy.
The problem arises because the 2.6.28 (or 2.6.29) kernel split the usbhid.ko driver apart, creating individual drivers for specific hardware. So, there is still usbhid.ko, but now also there are a heap of hid-*.ko modules. For my keyboard/mouse the appropriate driver is hid-logitech.ko.
Now, I have the 18.104.22.168 kernel configured to automatically load the hardware-specific driver when usbhid.ko loads -- this configure option is intended for use in an initramfs (intitrd). So, I built Puppy with all the hid-*.ko modules in the initrd, but my hid-logitech.ko still did not load -- that is the status-quo with Pup 4.3pre-beta-reloaded.
Today I found that what actually happens is when usbhid loads, it generates an appropriate uevent that can be used to load hid-logitech. It generates a kernel uevent with a line that has this in it ('x' means any non-blank char):
xxxx MODALIAS=hid:xxxxxx xxxxx
What threw me is that MODALIAS information does not appear in the /sys filesystem. As I don't use udevd in the initrd, I needed to somehow monitor kernel uevents after usbhid loads and detect that MODALIAS=hid:xxxx information. I tried 'hotplug2' but it is not "hid aware", so instead I used my 'hotplug2stdout' program.
'hotplug2stdout' is a daemon that logs kernel uevents. The 'init' scripts starts hotplug2stdout as a separate process, runs 'modprobe usbhid', then kills hotplug2stdout and examines the log. If an appropriate entry is found, modprobe is run:
All of the above explanation is for the benefit of those who are into the technical side of booting Puppy, hardware detection and module loading. However, for all of us, the end result is what matters!
No comments posted yet.