Ultrawide Display on Debian Linux

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.

  1. Generate a modeline for the new resolution: [1]

    cvt 2560 1080 30
  2. 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
  3. Add the mode to the HDMI interface. In my case it was named HDMI-0:

    xrandr --addmode HDMI-0 2560x1080_30.00
  4. 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 /usr/share/X11/xorg.conf.d/40-monitor.conf:

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

Upon reboot, 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 40-monitor.conf file:

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.


1. 60Hz worked for all the lesser resolutions, but when I tried 60Hz at the highest resolution, the display blacked out, so I had to drop back to 30Hz. It looks fine.


Adventures with the M3D Micro

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

  • stringing

  • speed

  • 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.

Update 2016-02-23

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.


Replacing a Drive in the Software RAID

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 and 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.


Impressions of SlimBean ROM for Nexus S

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.


All the Posts

November 2016

February 2016

December 2012

November 2012

October 2011

December 2010

May 2010

January 2010

August 2009

March 2009

November 2008

October 2008

March 2008

January 2008

December 2007

September 2007

August 2007

June 2007

May 2007

April 2007

March 2007

January 2007

November 2006

October 2006

September 2006

August 2006

July 2006

June 2006

May 2006

March 2006

February 2006

January 2006

December 2005

November 2005

October 2005

September 2005

August 2005

July 2005

June 2005

May 2005

April 2005

March 2005

February 2005

January 2005

November 2004

October 2004

September 2004

August 2004

July 2004

June 2004

May 2004

April 2004

March 2004

February 2004

January 2004

December 2003

October 2003

August 2003