Monthly Archives: December 2014

127: Compton, Multiple Screens, and Fedora 21

This post is anomalously numbered because it had its roots in an animation commentary that I got sick of writing. I will give here an account of my journey to get a dual-screen setup working in Fedora 21 on Openbox (with Compton). By the way, I’m still looking to package Compton for Fedora. Grrrr.

GNOME on Fedora 21 handles monitor hotplugging gracefully: the moment that HDMI cable went in, my primary display blinked; this signaled acknowledgment. Within seconds the secondary display was working. Openbox ought not be mentioned in the same sentence as GNOME: a window manager against a whole desktop environment is a side-by-side comparison to avoid.

While tools like arandr worked perfectly in Fedora 20, my screen did a bizarre shimmy when I tried to apply it to Fedora 21: specifically, my screen was shifted laterally and wrapped around itself. This usually meant the top half of the screen swapped places with the bottom half, and the position of my cursor on-screen did not correspond to its acknowledged position in the environment (e.g. I had to be clicking a point way below my desired target). Of course, I could open dmenu and execute “openbox –exit” with my eyes closed: this dropped me back to the GDM greeter and fixed my borked monitor configuration. When I next logged into an Openbox session, the secondary display (and the primary display!) worked fine.

Mind you, the whole point of my frustration was refusing to log off (dropping back to the GDM greeter) and re-login every time I wanted a secondary display: I shouldn’t have to save and drop all my work just to take a break on a big screen.

I first looked into Xorg: this was fruitless, as it turns out that xorg.conf has been obsoleted for a while now (since X11 apparently determines things on-the-fly and does so pretty well). The last bastion of X11 configuration, I believe, lives in /usr/share/X11/xorg.conf.d/ (on Fedora 21, at least).

I then turned my attention to a more obvious solution: some correction specific to my user account. I logged into my “makerpm” account and spawned an Openbox session for the first time. arandr did its job flawlessly and confirmed  my suspicions that the problem was not system-wide. This was something to be thankful for: I could scour my own files and scratch out a solution. I deleted a lot of dot-files (e.g. the whole of .local and .cache, paying attention to a monitors.xml file somewhere in the mess). No solvency.

At last, a Google search actually led to a serendipitous solution in this thread about my current compositor, Compton. The relevant portion is quoted:

Sorry for the late reply, jlindgren90, firstly.

  1. This is not necessarily a bug in compton. I couldn’t remember anything special that I need to take care of when Xinerama layout changes, except dealing with the new virtual screen size. I don’t remember seeing similar reports, and in VirtualBox it work correctly.
  2. Does forcing a full-screen repaint (for example, by switching to a virtual console then back) help?

The first point was conceptually important: compton may have been messing with things, though probably through some subtlety between interactions rather than an outright misbehavior on its part.

I tried dropping into a virtual console (Ctrl+Alt+F2) and back (Ctrl+Alt+F1). This fixed my primary screen from wrapping, restoring sanity to my workflow. The secondary monitor, however, refused to treat itself.

I tried restarting Compton (killall -s SIGUSR1 compton), which did the same as the above. Still no luck with the secondary window.

At last, I completely killed compton (killall -s SIGTERM compton) and waited a second to restart it. This fixed the problem completely: the secondary display repainted itself and began working as expected.

The expected workflow for connecting a second display to my machine is then:

  1. Kill compton.
  2. Connect the desired display and power it on.
  3. Have arandr (or similar) handle the secondary display.
  4. Start compton anew.
  5. Restart tint2 so that transparency works again.

Whew. Not simple by any means, but still a step up over having to log out and in again.



128: Shining Perl-y White

I tried to build myself a presence on GitHub with some little projects (hint: I’m not a substantial enough coder for this to work). I got myself started with qlqw, a little script that writes the contents of your current Quod Libet play queue. I use my queue almost exclusively, because it allows me to just dynamically build a never-ending playlist. On the rare occasion that something forces me out of my session without a clean exit, the queue on disk isn’t updated and when I restart Quod Libet I end up staring frustratedly at a long list of pieces already played and dequeued previously.

I was already most comfortable with Python by the time I chose to write qlqw, but I figured I should keep my C flowing for my own sake; so I shouldered the burden of writing a thoroughly script-ish application in an awesomely low-level language like one uses a tiger tank to assault an anthill. The horrendous result, preserved for posterity, is bloated and ill-suited for C.

For the longest time I resisted rewriting it. The C implementation was good enough, I told myself. Today, I had just finished a midterm and scratched a quick-and-dirty sequential tagger out in Python (that worked brilliantly, I should add) when finally I scratched the itch and said, “fine, fine, I’ll recreate my monstrosity.” The part of my brain that throttled common sense and decency cried out with joy, but I got in the last word: “I’ll only do it in Perl.” I mean, I hate to let common sense reign in my twisted world.

Five hours before, I had just about zero experience with Perl (except with print statements to induce buffer overflows in homework). In the space of maybe two hours, with copious Bing-fu, I produced a working version of qlqw with half the number of characters (either way I write as many comments as I do lines of code) in Perl.

I’m actually quite shocked and a little pleased. It’s (in retrospect, not surprisingly) easier to grab environment variables, unescape URL-encoded strings, execute system commands, and to get command-line flags in Perl than in C. I could even arbitrarily capture the stdout stream of a system command into a buffer pulled from a hat. Much of my C code is a mess. One of the space-savers (piping the output of “quodlibet –print-queue” through cut) was something I really can’t believe I didn’t think of when writing the C version.

I look forward to more experiments in Perl (time permitting) and pushing more commits to GitHub on my little pet projects.