A discussion a couple of days ago about DPI detection (which is best summarised by
this and
this and I am not having this discussion again) made me remember a chain of other awful things about consumer displays and EDID and there not being enough gin in the world, and reading various bits of the internet and wikipedia seemed to indicate that almost everybody who's written about this has issues with either (a) technology or (b) English, so I might as well write something.
The first problem is unique (I hope) to 720p LCD TVs. 720p is an HD broadcast standard that's defined as having a resolution of 1280x720. A 720p TV is able to display that image without any downscaling. So, naively, you'd expect them to have 1280x720 displays. Now obviously I wouldn't bother mentioning this unless there was some kind of hilarious insanity involved, so you'll be entirely unsurprised when I tell you that most actually have 1366x768 displays. So your 720p content has to be upscaled to fill the screen anyway, but given that you'd have to do the same for displaying 720p content on a 1920x1080 device this isn't the worst thing ever in the world. No, it's more subtle than that.
EDID is a standard for a blob of data that allows a display device to express its capabilities to a video source in order to ensure that an appropriate mode is negotiated. It allows resolutions to be expressed in a bunch of ways - you can set a bunch of bits to indicate which standard modes you support (1366x768 is not one of these standard modes), you can express the standard timing resolution (the horizontal resolution divided by 8, followed by an aspect ratio) and you can express a detailed timing block (a full description of a supported resolution).
1366/8 = 170.75. Hm.
Ok, so 1366x768 can't be expressed in the standard timing resolution block. The closest you can provide for the horizontal resolution is either 1360 or 1368. You also can't supply a vertical resolution - all you can do is say that it's a 16:9 mode. For 1360, that ends up being 765. For 1368, that ends up being 769.
It's ok, though, because you can just put this in the detailed timing block, except it turns out that basically no TVs do, probably because the people making them are the ones who've taken all the gin.
So what we end up with is a bunch of hardware that people assume is 1280x720, but is actually 1366x768, except they're telling your computer that they're either 1360x765 or 1368x769. And you're probably running an OS that's doing sub-pixel anti-aliasing, which requires that the hardware be able to address the pixels directly which is obviously difficult if you think the screen is one size and actually it's another. Thankfully Linux takes care of you here, and
this code makes everything ok. Phew, eh?
But ha ha, no, it's worse than that. And the rest applies to 1080p ones as well.
Back in the old days when TV signals were analogue and got turned into a picture by a bunch of magnets waving a beam of electrons about all over the place, it was impossible to guarantee that all TV sets were adjusted correctly and so you couldn't assume that the edges of a picture would actually be visible to the viewer. In order to put text on screen without risking bits of it being lost, you had to steer clear of the edges. Over time this became roughly standardised and the areas of the signal that weren't expected to be displayed were called overscan. Now, of course, we're in a mostly digital world and such things can be ignored, except that when digital TVs first appeared they were mostly used to watch analogue signals so still needed to overscan because otherwise you'd have the titles floating weirdly in the middle of the screen rather than towards the edges, and so because it's never possible to kill technology that's escaped into the wild we're stuck with it.
tl;dr - Your 1920x1080 TV takes a 1920x1080 signal, chops the edges off it and then stretches the rest to fit the screen because of decisions made in the 1930s.
So you plug your computer into a TV and even though you know what the resolution really is you still don't get to address the individual pixels. Even worse, the edges of your screen are missing.
The best thing about overscan is that it's not rigorously standardised - different broadcast bodies have different recommendations, but you're then still at the mercy of what your TV vendor decided to implement. So what usually happens is that graphics vendors have some way in their drivers to compensate for overscan, which involves you manually setting the degree of overscan that your TV provides. This works very simply - you take your 1920x1080 framebuffer and draw different sized black borders until the edge of your desktop lines up with the edge of your TV. The best bit about this is that while you're still scanning out a 1920x1080 mode, your desktop has now shrunk to something more like 1728x972 and your TV is then scaling it back up to 1920x1080. Once again, you lose.
The HDMI spec actually defines an extension block for EDID that indicates whether the display will overscan or not, but doesn't provide any way to work out
how much it'll overscan. We haven't seen many of those in the wild. It's also possible to send an HDMI information frame that indicates whether or not the video source is expecting to be overscanned or not, but (a) we don't do that and (b) it'll probably be ignored even if we did, because who ever tests this stuff. The HDMI spec also says that the default behaviour for 1920x1080 (but not 1366x768) should be to assume overscan. Charming.
The best thing about all of this is that the same TV will often have different behaviour depending on whether you connect via DVI or HDMI, but some TVs will still overscan DVI. Some TVs have options in the menu to disable overscan and others don't. Some monitors will overscan if you feed them an HD resolution over HDMI, so if you have HD content and don't want to lose the edges then your hardware needs to scale it down and let the display scale it back up again. It's all awful. I recommend you drink until everything's already blurry and then none of this will matter.
comments
I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances.
No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle).
I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.
It took me much more uploads than I expected, but 
By now hopefully you got a chance to see my Jeopardy! episode so it won't be much of a spoiler to mention that I didn't win.
It went like this. I flew into LA on the night of October 31st. The taping was to take place on the next two days. Jeopardy! tapes two weeks of shows, two days a week for a total of 10 episodes. Contestants are randomly chosen for one of those 10 episodes but you don't find out which one you will be on until the last minute. Randomness and secrecy have become become a big part of the production process in games since the 
We are about to lose 
I use 
This is my monthly summary of my Debian related activities. If you re among the people who 
Dpkg and Multiarch
I had some hope to have a multiarch-enabled dpkg in sid for Christmas as Guillem told me that it was realistic. Alas Guillem got sick. We re in January and we re still not there.
While some of Guillem s commits in December were related to multi-arch, the size of his 
Misc dpkg work
I reviewed (and later merged) a patch of Kees Cook to enhance dpkg-buildflags so that it can report which hardening features are enabled. This feature might then be used by tools like lintian to detect missing hardening features.
I 
Last year, my new year's resolution was to write in my journal every day.
That actually stuck, I wrote 262 journal entries in 2011. While I've been
keeping a journal intermittently since 1998, last year I doubled the number
of entries in it. And wrote a novel's worth of entries -- 53 thousand words!
Most of it is of course banal and mundane stuff. Not good compared with
Lars, who does something with his journal where he goes into some detail
about code he's working on, and other work. The excerpts I've seen are
quite nice. But after I've written code, written a commit message,
documentation, perhaps bug reports etc, I often can't find much to say
about it in my journal, beyond the bare bones that I worked on $foo today or
faced a particularly hard bug. I also worry that the journal, and my
reluctance to repeat myself, often tips the balance away from me blogging,
if I write down something in the journal first.
a rather lazy bugsquashing week but with a little cheating a managed to get
at at least 7 RC bugs:
I've been informed by a couple of people that the 
The