Down the Rabbit Hole

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.

_1310382
Fitlet X-Lan all wired up

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?”

_1310392
The old RAID machine

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:

_1310381
New spiffy machine

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.

Leave a Reply