The advice in this entry is now outdated — see my newer post on the subject.
My beloved netbook, an Asus EeePC 1005HA, which is otherwise wonderful, has one inherent problem: its screen is small. Not just physically small, but also small in pixels, only 1024×600, and since it’s an LCD that’s the only resolution you get. Not a lot of programs these days expect only 600 pixels of vertical space, and most of them produce configuration menus that fall off the bottom (as the rest of this post makes clear, I spend a lot of time in configuration menus). For the longest time I was using
to give myself a comfortable virtual desktop, but then I upgraded to Ubuntu 11.04 (Natty, I believe? I don’t use names) and Unity broke it. Unity has done that a lot to me, which is why I didn’t upgrade until yesterday. But I beat it, and learned something cool in the process.
Here’s what I used to do: the command
xrandr --output LVDS1 --mode 1024x600 --fb 1024x768 --panning 0x768 tells X that although my physical screen is at its natural resolution of 1024×600, I also want a simulated screen of 1024×768 (starting at the upper-left, so the excess space ends up below the lower edge) and I want to be able to pan the view over this virtual space by pushing the upper and lower edges with the mouse.
That mysterious 0x768 means “no panning horizontally”; of course, it’s the same as
--panning 1024x768 because the virtual and physical horizontal sizes are the same. But it causes different behavior: until Ubuntu 10.04, the window manager would somehow understand that I wanted everything to fit into the physical screen if possible, so maximized windows would fill only the screen, and not overflow. Of course, I use Ubuntu Netbook, whose nice launcher (both then and, with Unity, now) maximizes everything by default.
No longer! In 11.04 the 0x768 line makes Unity draw a big black bar in the extra space, and nothing can be seen there even if it’s put. However, the 1024×768 line makes maximized windows too large. At first I was frustrated, but I didn’t even know where to try to change it. And you know how useful Ubuntu documentation is. So I was pretty happy when I found this Ubuntu Forums thread about the same problem! Naturally I went and typed
unity --replace into my terminal straight away. Naturally it didn’t work, leading to my filing this bug at Launchpad. Yes, what actually happened is that the contents of a 1024×600 screen were forcibly stretched to fit the 1024×768 screen, resulting in a sight of garbled fonts and flickering windows (and weirdly displaced buttons) from out of the ’90s.
Then I found the Compiz configuration tool which, atypically for Ubuntu, provided numerous and detailed controls for every aspect of window management (without using
gconf!). Alas, it is all too typical in its lack of helpful documentation. I spent about four hours clicking through the various things that might affect the size of virtual desktops, viewports, and window maximizing behavior, none of which seemed to. I also found this question on AskUbuntu, which is more or less my question. The answer, of course, didn’t work: Maximumize, while interesting, first of all seems not to work so well, and second of all does not actually maximize in the technical sense, and with Unity, that affects the styling of the title bar. I do not accept compromise in the styling of the title bar.
I fell into a black mood and wrote a question there myself, but it appears to have been entirely ignored. I ate dinner. I reread some more of Warbreaker. I played with my pet rat. Perhaps the rat’s example gave me the inspiration to poke around some more in Compiz, for I came across the innocuous menu item “General Options”. Hmm. There is a “Display Options” tab but I don’t know what any of it means. Well, for once Google turns up a page that tells me something, however little: this wiki page. Note that half the options given there don’t actually appear in this tab. But I do learn that Compiz autodetects the size of my screen. I guess that’s how it knows that I am “supposed” to have a 1024×600 screen even though I told it otherwise.
My “outputs” box in that tab reads “1024×600+0+0”, and the obvious thing to do is change that 600 to 768. Nothing. I read the wiki again. Ah: underneath the table of options there is a note: “outputs” only does something if “Detect outputs” is disabled (makes sense). I do that. Now Compiz doesn’t stretch me anymore, but it does maximize windows over the whole 768 pixels, which is no good; however, I am clearly on the right track.
I set it back to the default, and I get the stretching glitch again (note: every time this happens, the only way I can fix it is to log out and back in or, if I am unlucky and hit the wrong button because none of them are in the right spot, I have to reboot). It occurs to me that I should not be telling Compiz that I have 600 pixels when in fact I have 768, but also that telling it I have 768 leads it to do the wrong thing. If only there were a way to get it to ignore the bottom 168…
Ah, that’s what the offsets are for. I put in “1024×600+0-168”, and the bottom 168 pixels are indeed ignored: they are permanently black and nothing can be drawn there. Well, at least I know now why that happens. But if I have to tell it one thing to get it not to stretch, and another thing to get it not to fill, how do I tell it to do both at once?
I look again: there’s a mysterious option I had never understood, called “Overlapping output handler”. How could you have overlapping outputs? Most people have only one screen, and if they have more they are always physically separate….oh, I get it! An “output” is not a screen at all; it’s just a box in graphics memory that Compiz will draw in. Of course, it should be on the screen, but that “outputs” box has plenty of space for another one, so I put in both 1024×768 and 1024×600+0-168. And here’s where the handler comes in: it needs to prefer the smaller output when given a choice, because I don’t want things spilling over into those bottom pixels. And it works.
So here’s how to have a panning screen in Unity: run
xrandr to set a framebuffer and panning, and set Compiz to have two outputs, one of the natural size with an offset and one of the virtual size; disable output detection; and set the handler to prefer the smaller one. This gives you an extended space that doesn’t affect any of your normal operation, unless Kile opens up a giant config menu that can’t be resized (as it does). Then you’ll thank me.