Aaargh!
I was going to do a simple switcharoo. The tiny firewall machine at home had shown itself to be slightly unstable. Not egregiously, but it seems like it’ll die every four months or so. That’s kinda annoying.
So I got a new, spiffier tiny machine. Copying over the setup from the old machine should take five minutes. At most. But then I started thinking.
WARNING! THERE IS NOTHING OF INTEREST IN THE REST OF THE BLOG POST UNLESS YOU”RE INTO EXTREME LINUX B&D!!!1!
This is what I thought: “This machine has a better CPU and graphics card than the machine I’m currently using as the music RAID/music ripping/charging headphones/scanning machine. Perhaps I should just make this a firewall/RAID/music/charging/scanning machine and have one fewer machines at home?”
You can see where this is going.
Three six hour days later, things are kinda starting to work.
I think the base problem is that I’ve got a mixed setup of newer stuff and older, not very well supported stuff that was unusual even back then.
Here’s the lsusb output:
root@potato:~# lsusb Bus 004 Device 004: ID 1781:0c30 Multiple Vendors Telldus TellStick Bus 004 Device 003: ID 041e:30c4 Creative Technology, Ltd Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 004: ID 0409:005a NEC Corp. HighSpeed Hub Bus 003 Device 003: ID 0bda:8723 Realtek Semiconductor Corp. Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 005: ID 0bc2:3320 Seagate RSS LLC SRD00F2 [Expansion Desktop Drive] Bus 002 Device 004: ID 0bc2:ab31 Seagate RSS LLC Bus 002 Device 003: ID 059f:106e LaCie, Ltd Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 008: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen Bus 001 Device 007: ID 17e9:0288 DisplayLink Bus 001 Device 006: ID 0a81:0205 Chesen Electronics Corp. PS/2 Keyboard+Mouse Adapter Bus 001 Device 005: ID 0409:005a NEC Corp. HighSpeed Hub Bus 001 Device 004: ID 080c:0300 Datalogic S.p.A. Gryphon D120 Barcode Scanner Bus 001 Device 003: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 002: ID 04b8:0129 Seiko Epson Corp. ES-10000G [Expression 10000XL] Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Yeah, I know. In addition there’s two eSATA CD-ROMs and the internal SSD.
First of all, this machine is quite picky about what USB hubs it’ll accept. I’ve got three USB3 hard disks (that make up the /music RAID) connected via a USB3 hub, because there’s only two USB3 connectors on this machine. With the first hub I tried, Linux was unable to detect the disks. Unless I plugged them in one at a time. My guess would be a power management problem. With a different, cheap powered USB3 hub, everything works fine.
For the non-USB3 things I had a different powered hub, and when that was plugged in, the BIOS wouldn’t boot. Fortunately there’s six USB2 sockets, so I was able to connect most of the things directly, and it seems to accept having the headphones etc connected via a cheap unpowered small hub, as seen here:
After getting all the USB power situation figured out (which took a while), I started checking the individual devices. Most things just worked (like the USB speaker, the Epson USB scanner, the eSATA CD-ROMs, Tellstick, the Datalogic barcode scanner…), but the USB monitor (Mimo Monztor 10″) refused to switch to monitor mode.
It comes up in CD-ROM mode (with some installation software), and you’re supposed to run usb_modeswitch on it to switch it to the udlfb mode.
USB description data (for identification) ------------------------- Manufacturer: DisplayLink Product: Monztor S10 Serial No.: 10270020 ------------------------- Change configuration to 1 ... Device is busy, try to detach kernel driver Looking for active driver ... OK, driver detached Device is busy, try to detach kernel driver Looking for active driver ... No active driver found. Detached before or never attached Device is busy, try to detach kernel driver Looking for active driver ... No active driver found. Detached before or never attached Device is busy, try to detach kernel driver
Hm. Busy? I guess, because the usb-storage driver claims it. So then I thought: Could I make usb-storage not do that? I can’t disable usb-storage, since I need that for the /music RAID, but can I make usb-storage hand it over? Indeed I can. This is my solution:
First, make Linux identify the “disk” by giving it a name:
root@potato:~# cat /etc/udev/rules.d/20-monztor.rules
SUBSYSTEM=="block", ATTRS{idVendor}=="17e9", ATTRS{idProduct}=="0288",
MODE="0666", SYMLINK+="monztor"Then I use the following script:
#!/bin/bash
device=$(basename $(realpath /dev/monztor))
for file in /dev/disk/by-path/*; do
candidate=$(basename $(realpath "$file"))
if [ "$candidate" == "$device" ]; then
id=$(echo "$file" | sed 's/.*usb-[^:]*://' | sed 's/-.*//')
for uid in /sys/bus/usb/drivers/usb-storage/*; do
suid=$(basename $uid | sed 's/^..//')
if [ "$suid" == "$id" ]; then
result=$(basename $uid)
fi
done
fi
done
echo $result
Then I start X this way:
root@potato:~# cat /etc/init.d/xinit
#!/bin/sh
case "$1" in
start) echo -n "Starting display"
if true; then
rmmod udlfb
sleep 10
/root/find-monztor > /sys/bus/usb/drivers/usb-storage/unbind
sleep 2
modprobe udlfb fb_defio=1 console=1
sleep 5
usb_modeswitch -v 0x17e9 -p 0x0288 -u 1
sleep 1
/usr/bin/X :1 -depth 16 -xf86config /etc/X11/xorg.conf.mimo -sharevts -noreset -s 0 &
fi
su - larsi -c "xinit -- /usr/bin/X :0 -depth 24 &"
echo "."
;;
esac
Yeah, look at all them sleeps… This is all kinda timing sensitive, but with these very generous pauses between each action, the boot is 100% reproducible. But it should be done in a less hacky way, of course, but whatevs.
Now, you’d think, everything is hunky dory?
What’s going on with the mouse pointer? It just stands there, shaking…
And then it occurred to me that the Monztor monitor is a touch monitor, and perhaps it doesn’t… really work with a modern version of Linux? This is what xinput –list says:
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ CHESEN PS2 to USB Converter id=11 [slave pointer (2)]
⎜ ↳ eGalax Inc. USB TouchController id=13 [slave pointer (2)]
⎜ ↳ eGalax Inc. USB TouchController id=12 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ CHESEN PS2 to USB Converter id=10 [slave keyboard (3)]
↳ Creative Technology Sound BlasterAxx SBX 8 id=14 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=15 [slave keyboard (3)]
∼ © Datalogic 2002 Datalogic Bar Code Scanner id=9 [floating slave]
Yup, there it is. The eGalax thing has to be the Monztor. So how to disable that? The xinput command can do all sorts of things, but it’s not very user friendly. I made the following little command that’ll output device IDs based on regexp matches:
#!/bin/bash
match="$1"
if [ "$match" = "" ]; then
echo "Usage: $0 "
exit
fi
xinput --list | grep "$match" | sed 's/.*id=\([0-9]*\).*/\1/'
And then I can say things like
# Disable input from the Mimo monitor touch screen, because it's
# buggy and shivering.
for id in `xlist eGalax.*pointer`; do
xinput set-int-prop $id "Device Enabled" 8 0
done
Presto! No shaking! But then I noticed that whenever I did something on the main screen, the events were also passed to the second X server running an mplayer showing random youtube clips.
And xinput doesn’t take a –display parameter. This is how I disable that:
# Disable all pointers and keyboards on the other screen xterm -display :1 -e \ 'for id in `xlist .`; do xinput set-int-prop $id "Device Enabled" 8 0; done'
See? SIMPLE!!!
But now the little monitor is showing the temperature and a youtube clip vaguely of the same thing that my stereo is playing. Back to normal.
So does Linux suck? Of course. But I’m making it do some pretty weird stuff, and I’m kinda surprised this all works at all. My guess is that on any other OS using this range of obscure hardware, this would have been just as awful. Although perhaps I wouldn’t even have attempted it.
And I just had to rebuild the RAID two or three times during this process. I mean, c’mon.