The other day I was debugging my awesome configuration and I zooted it. I had missed a comma in a table and the Lua stuff puked on me and awesome stopped working. So I went and dropped into a tty console to fix the problem.
Except my tty console was blank!
I tried all 6 of them and they were all blank. I was able to fix the configuration problem using other means, but I resolved to investigate where my tty consoles had gone.
Turns out that they are there- except nothing is being displayed on them. I’m still not sure why this is, I just know that it’s related to the framebuffer. How did I figure that much out? Well, for starters, the following command:
dmesg | grep vesafb
revealed the framebuffer was being run at 800x600x32. The 32-bit color depth seemed sketchy to me. After some googling, I discovered a nice little utility called hwinfo. I installed it and then entered the following:
hwinfo --framebuffer
Sure enough, 32 bit color is not supported at 800×600. Unfortunately, using the alternative settings (I tried 800x600x24, 800x600x16 and 800x600x8) still did not give me the result I wanted. Of these 3 options, the 24 bit color option came close, but still didn’t give me what I wanted.
Just occurred to me that it might help if I described some of the results. I have grub2 installed and have been, since installing grub2, using the gfxpayload setting to setup my tty resolution. Basically, with the original setting gfxpayload=800x600, the boot sequence displayed at 800×600 but my tty consoles were blank. This setting corresponds to the 32 bit color I mentioned earlier. If I set the color depth to 24 bits, the boot sequence would run at 640×480 and the tty consoles worked at 800×600. For the 16 and 8 bit color, the boot ran at 800×600, but my tty consoles were blank. In fact, at 16 bits, after switching to a tty, I was unable to bring back X on tty7! Using dmseg I did confirm that each setting was running as specified, so it seems that grub was setting up the framebuffer.
For now, I’ve commented out my gfxpayload line in the 00_header file. This change causes the screen to boot at 640×480, but still allows my tty’s to work- and at 800×600! Previous, without gfxpayload, everything ran at 640×480. Not sure what the color depth is. Interestingly, entering dmesg | grep vesafb yields no results. I can only assume this means the framebuffer is not being used.
I’d like to understand this a little more. Finding documentation on it is difficult; though finding other people with interesting video problems is easy enough. I don’t want to submit a bug report because I’m not sure what, if any, bug there might be. The DebianEEE Wiki doesn’t mention anything about this problem, so perhaps I’m the only one.