cvt 2560 1080 30
27 November 2016
I picked up a very-slightly-used 34-inch LG 34UM67 display to use on my Debian Linux workstation that I use for processing photos. It’s an IPS display with 2560x1080 pixels, so that should fit nicely with photo work.
The built-in graphics on my Dell T20 only supports VGA, so I also needed to buy a new video card to support HDMI. My needs are modest, so I picked out an Asus ATI Radeon HD6450. I’ve always gone for ATI/AMD and Intel when I could, since their fully open-source versions of drivers have worked well in the past. I’m also not a gamer, so I can skip over Nvidia.
Upon plugging it all together, I needed to ensure I had all the "amdgpu" packages installed from Debian Unstable, so I could get higher resolutions beyond VGA.
It still didn’t recognize the crazy-wide 21:9 aspect ratio out of the box, so I still had some work to do. By default, the display awkwardly stretched the card’s 1920x1080 across the whole screen. That can be fixed in the display: Menu → Quick Settings → Ratio → 1:1, and then you’ll have letter boxes on the sides, but no stretching.
That left me still needing to convince my Xorg xserver to use the rest of the screen, all 2560x1080 pixels. I found a stackexchange article which provided me just about everything I needed.
Generate a modeline for the new resolution: 
cvt 2560 1080 30
Create that new modeline dynamically. In my case mine, looked like this:
xrandr --newmode "2560x1080_30.00" 106.75 2560 2640 2896 3232 1080 1083 1093 1102 -hsync +vsync
Add the mode to the HDMI interface.
In my case it was named
xrandr --addmode HDMI-0 2560x1080_30.00
Then switch to it:
xrandr --output HDMI-0 --mode 2560x1080_30.00
Once I had proven these settings to work nicely,
I obviously wanted to keep them,
so I persisted them by creating a file for them
in the xorg config directory along-side the existing configs
that Debian provides.
I called my file
Section "Monitor" Identifier "HDMI-0" Modeline "2560x1080_30.00" 106.75 2560 2640 2896 3232 1080 1083 1093 1102 -hsync +vsync Option "PreferredMode" "2560x1080_30.00" EndSection
everything was working,
and I was happy for a week or 2,
but I noticed performance wasn’t great during fast 2D updates.
I was seeing some tearing
when I’d play a video in full-screen
or even a large window.
I dug around a little in the
amdgpu(4) man page
and found a couple more options to add to my
Section "Device" Identifier "AMDgpu" Option "TearFree" "on" Option "ShadowPrimary" "on" EndSection
Those final adjustments solved the performance problem for me. I expect those adjustments may only be specific to the cheap card I bought, though.
Next I’ll need to figure out how to speed up my mouse, since it’s such a long way from one side of the screen to the other. I’ll also further rethink the windows I keep beside one another.
I bought the display figuring Linux can be made to do anything, and I was right. I just needed to figure out how.
12 February 2016
The kids got a little M3D Micro for Christmas, and so started our adventures into 3D printing.
I intended to let the kids learn the whole thing from scratch, but I knew I was throwing them a little bit of a curve ball by only having Linux netbooks to drive it, so I ended up getting a headstart setting up OctoPrint and the M3D-Fio driver.
At the end of December 2015 when I was starting, the M3D-Fio driver had some configurations in the repository that might not have been optimal, so I was fighting a bit with a few problems:
adhesion to the bed
gaps and lines in the bottom layers
other quality issues
I thrashed around for quite some time changing settings I didn’t really understand, and Matthew spent a night helping me and showing me what his much larger printer could do — that helped immensely, since it gave me some hints as to what I should be expecting from my printer. I also learned what the different settings should be doing for me.
For an entire Sunday, about 18 hours, I printed 1cm test cubes and experimented with settings. I quickly decided I should have my settings and profiles tracked in my own local git repository, so I can always rollback to previous settings.
After a week or so, some updates from the M3D-Fio repository brought us more success with more default settings that matched the defaults found in the original software from Micro. The conservative settings also added rafts and slowed down the print a bit.
I was able to take those conservative settings and speed them up a bit and remove the rafts — the BuildTak holds a print pretty well even without the raft. I based my customizations on the stock profile that prints at 0.25mm layer thickness to get even more speed out of the printer.
I also found keeping a -0.4mm bed offset on my printer helped get just enough squish in the first layer to help get a more solid bottom layre and good adhesion to the bed.
Another notable configuration tip I had picked up was to set the wall thickness to a multiple of the nozzle size. In the case of the M3D, the nozzle thickness is 0.35mm, so I’m using a thickness of 0.70mm. Before I had learned that, a couple of my initial chachkies came out with thin gaps where the slicer should have decided to fill.
I’m at the point now that I have pretty reasonable expectations for what the printer can do, and I can start up the machine after a week or 2 of sitting, and run a print through reliably without needing to make adjustments. That’s great for letting the kids just make whatever they want. Both kids have been able to get into Tinkercad and produce some printable designs. Ben’s doing Nerf rail accessories, and Marie is designing a new cap for my growler.
Finally, I’ve pushed my configurations to a public git repository to serve as reference for anyone else who cares.
An update added a slicker settings dialog to allow more intuitive adjustments to a profile, so I’ve been testing relatively successfully with using the stock PLA profile and just flipping options. I did find that using a raft in "medium quality" mode fused my little 10mm test cube to the raft in a way that I can’t remove it. I usually avoid the raft anyway, though, since it sticks so well to the buildtak already.
13 December 2012
I realized upon trying to replace a drive in my Linux software RAID, that I had never previously documented this process.
The power failed a couple days ago, and sitting around for 10 hours not spinning was bad for my one Western Digital 500GB drive, so it never came back online, but the computer booted up just fine with 2 of the 3 drives. I ordered a new 1GB drive to replace it within 2 hours of the problem.
When the new drive arrived, I shutdown the computer, unplugged the failing SATA drive, and replaced it with the new one. Linux again booted up with only 2 drives active.
To ensure that the partitions matched, I did an
sfdisk -d /dev/sda | sfdisk /dev/sdb.
cfdisk was unhappy with the drive initially, but
fdisk was happy to read the table and write it back cleanly. Then I could open it again in
cfdisk and add one more primary partition to use the extra non-redundant 500G on the new drive.
With the partitions in place, it was time to insert the new
partitions back into the RAID devices:
mdadm /dev/md0 --add /dev/sdb1,
mdadm /dev/md2 --add /dev/sdb5, etc, until all the drives were re-established. Watching
/proc/mdstat, I could see that the RAID started recovering the devices, and I could go to bed.
I did manage to do something wrong at one point, so a quick
mdadm /dev/md0 --fail /dev/sdb1
mdadm /dev/md0 --remove /dev/sdb1 allowed me to fail and remove a partition, fix it up, then add it back when I was done. All this could be done with the system up and running—that's pretty convenient.
16 November 2012
I've had my Nexus S for about a year and a half now, and I was stuck on an old stock Android for a long time—the AT&T version of this phone just never got the updates, so Matt helped me out and got me started with CM9 on the device back in the Spring.
Since getting some experience rooting and romming, I've tracked CM9, tried CM10, loaded stock Android 4.0 and 4.1. I found my device with stock 4.1 with my usual loaded apps (like BeyondPod, Tasker, etc) to be a little light on RAM. BeyondPod kept getting pushed out of memory when, really, it's my #1 app for daily use.
I needed to free up some memory, so I figured SlimBean would be worth a look. It seems to be based on AOSP with some of the most useful features of other ROMs merged, like notification toggles, etc. It's also relatively easy to install, though the upgrades keep recommending a full wipe and reinstall, which can be inconvenient, even with a ROM Toolbox doing my backup and restore of applications.
One of the most notable features is that the default DPI is set low (182ppi), so everything ends up tiny. Couple that with a tighter grid-size in Hololauncher and you can cram lots of app icons and widgets on the screen. I at one point bumped it back up to 200 to get it just a little more readable, but in the latest install, I've just been leaving it set to the default.
Amazon Appstore offered me my first problem. ROM Toolbox half restored it, but not the whole way, so it had some data files laying around but not the rest of the app. When I went to install it again from APK, it kept telling me "App is not installed". I finally figured out in this last time I wiped and installed, that I needed to delete the Appstore's data directory in Root Browser, and then it happily installed.
In the end, I'm not sure I gained much free memory—it still seems tight, and applications are still quick to get pushed out. I think what's slim about the ROM, is that it merged in some select features from CM and others without taking up as much space for everything those other ROMs offer. I like this ROM, and I hope to see it make Android 4.2.x and later available on my little Nexus S.